why there is lot differences in download speed between framework and dotnet

[OurIslam]

getstream httpclient StreamAsync dotnet [framework 481 or lower] download speed 6-8 mb per second and very smooth download process but when same project httpclient StreamAsync[ .net 7 or lower] getting 1-2 mb per second also lot of hang and also very very laggy process ? why ??

[ghost]

Tagging subscribers to this area: @dotnet/ncl See info in area-owners.md if you want to be subscribed.

Issue Details

---

getstream httpclient StreamAsync dotnet [framework 481 or lower] download speed 6-8 mb per second and very smooth download process but when same project httpclient StreamAsync[ .net 7 or lower] getting 1-2 mb per second also lot of hang and also very very laggy process ? why ??

Author:	developerss
Assignees:	-
Labels:	`area-System.Net.Http`, `untriaged`
Milestone:	-

[karelz]

@developerss that is hard to believe. Do you have a minimal repro you can share? If you were testing on .NET 6.0, we had a perf problem with HTTP/2 with large RTT, which we fixed in .NET 7.0. Beyond that we are not aware of any perf problems in the space.

[ghost]

This issue has been marked needs-author-action and may be missing some important information.

[OurIslam]

                var client = new HttpClient();
                HttpRequestMessage httpRequestMessage =
                    new(HttpMethod.Get, DownloadUriAddress);
                SetRequestClientRange(ref httpRequestMessage);

                var response =
                    await client.SendAsync(httpRequestMessage,
                    HttpCompletionOption.ResponseHeadersRead, token).ConfigureAwait(false);
                var streaming = await response .Content.ReadAsStreamAsync(token).ConfigureAwait(false);

                using (destinationStream = new ThrottledStream(streaming))
                    {
                        byte[] buffer = new byte[8120];
                       readSize = await destinationStream.ReadAsync(---->>>>;
                       await disk.Storage.WriteAsync(-->>>
                    }

or direct test var stream = await client.GetStreamAsync(DownloadUriAddress).ConfigureAwait(false);

same dotnet vs .net big difference download speed

dotnetframework

.net or other netcore

if possible give me a explain why this happen its

[karelz]

@developerss can you please post a repro we can try on our side as well? (minimal one) The above code uses types and methods which are not posted.

BTW: Do you see same results against different URL, or is it specific to some URL? Did you try to check if the same HTTP version is used -- e.g. via Wireshark?

[ghost]

This issue has been marked needs-author-action and may be missing some important information.

[wfurt]

ThrottledStream certainly looks suspicious :) I would suggest to simplify and and remove any extra crust. Perhaps just measure pure download and take a peek with Wireshark as @karelz suggested. This issue is really not actionable at the moment.

[OurIslam]

BTW: Do you see same results against different URL, or is it specific to some URL?

Tried in different URL have same result and same URL have same result between dotnet and framework. Framework give bigger faster result, .NET is very slow and too many lagging, otherside Framework have no lag smooth performance.

Did you try to check if the same HTTP version is used -- e.g. via Wireshark?

I do not know what is Wireshark? But I tried 1.1 httpversion in both , the result same, In .NET 7 I tried also different HttpVersion 20 and 30 both have same result nothing improve in part of stream reading

repro ? its mean I have to provide the URL that I am testing ?

file part = file url lenth / 100

[liveans]

repro ? its mean i have to provide the url that i am testing ?

Repro means: Reproduction project

Edit: You can take a look at #72177 for an example.

[ghost]

This issue has been marked needs-author-action and may be missing some important information.

[MihaZupan]

As part of the repro, please also remove the ThrottledStream. Immediately at least one bug in it is that it throttles based on the buffer size, not on the number of bytes actually read.

[ghost]

This issue has been automatically marked no-recent-activity because it has not had any activity for 14 days. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will remove no-recent-activity.

[karelz]

Triage: No clarity on repro that it would be real problem in .NET. Closing. Feel free to reopen if there is more evidence it is a problem in .NET and not in the test code.