一連の同期 Web リクエストが順次実行される場合、Web リクエストを完了するのに数秒かかり、 1 秒あたりのバイト数Nを受信します。Bただし、まったく同じことを行いますが、非同期 Web 要求を使用すると、すべての Web 要求を並行して実行できます。数秒かかることはありませんが、 1 秒あたりのバイト数Nは引き続き受信されます。B
同期アプローチと並列アプローチの両方を使用して、12 個の Web 要求で簡単なテストを実行すると、両方がB1 秒あたりのバイト数を受信することが確認されます (を使用Resource Monitor)。
したがって、私の質問は... Webリクエストを並行して実行するアプローチはB、同期アプローチよりも高速であることを補うために、1秒あたりのバイト数を超えないようにする必要がありますか? - それ以外の場合、同期アプローチは、並列アプローチよりも長く実行され、(合計で) より多くのバイトを受け取ります。
These requests are not processed on your machine (unless connecting to localhost). This means that for each request to be fully processed, your machine will have to wait for a response.
Consider sending an invitation for your birthday party to friend #1, and after receiving a response, send one to friend #2, etcetera. It would be faster to send the invitation to all friends, and then wait for all of them to respond. Especially if friend #1 happens to be on holiday.
I don't know why the number of bytes per second are identical, perhaps some node in the network limits the speed, but the parallel approach can at least send out each request and "parallel out" the total wait time.
I don't understand how the synchronicity could affect the total number of bytes received. You're talking about bytes/second, but not the number of seconds spent at that transfer speed.