特にこのソースから非同期 Web 開発の概念を調査した結果、その概念を証明するサンプル アプリケーションを作成しました。
このソリューションは、2 つの ASP.NET Web API アプリケーションで構成されています。1 つ目は、シミュレートされた遅いエンドポイントです。Student というカスタム クラスのリストを返す前に、1000 ミリ秒待機します。
public IEnumerable<Student> Get()
{
Thread.Sleep(1000);
return new List<Student> { new Student { Name = @"Paul" }, new Student { Name = @"Steve" }, new Student { Name = @"Dave" }, new Student { Name = @"Sue" } };
}
学生クラスは次のとおりです。
public class Student
{
public string Name { get; set; }
}
このエンドポイントは、localhost:4002 の IIS 7 でホストされています。
2 番目のアプリケーションは、1 つは同期、もう 1 つは非同期の 2 つのエンドポイントを使用して最初のアプリケーションに接続します。
public IEnumerable<Student> Get() {
var proxy = WebRequest.Create(@"http://localhost:4002/api/values");
var response = proxy.GetResponse();
var reader = new StreamReader(response.GetResponseStream());
return JsonConvert.DeserializeObject<IEnumerable<Student>>(reader.ReadToEnd());
}
public async Task<IEnumerable<Student>> Get(int id) {
var proxy = new HttpClient();
var getStudents = proxy.GetStreamAsync(@"http://localhost:4002/api/values");
var stream = await getStudents;
var reader = new StreamReader(stream);
return JsonConvert.DeserializeObject<IEnumerable<Student>>(reader.ReadToEnd());
}
localhost:4001 の IIS 7 でホストされています。
両方のエンドポイントが期待どおりに機能し、約 2 秒で戻ります。1秒。上記のリンクのビデオの 13:25 に基づいて、非同期メソッドはそのスレッドを解放し、競合を最小限に抑える必要があります。
Apache Bench を使用してアプリケーションのパフォーマンス テストを実行しています。10 個の同時要求がある同期メソッドの応答時間は次のとおりです。
これは私の予想通りです。同時接続が増えると、競合が増加し、応答時間が長くなります。ただし、非同期応答時間は次のとおりです。
ご覧のとおり、まだいくつかの競合があるようです。平均応答時間はもっとバランスが取れていると思っていたでしょう。50 の同時リクエストで両方のエンドポイントでテストを実行すると、同様の結果が得られます。
これに基づいて、非同期メソッドと同期メソッドの両方が多かれ少なかれ同じ速度 (予想) で実行されているように見えますが、非同期メソッドのオーバーヘッドは考慮されていませんが、非同期メソッドはスレッドを解放していないようですスレッドプールに。コメントや説明をお待ちしております。