❔ ✅ Writing to response body is slow in .net core 7 web api?
Hey guys, I have a stack overflow thread about the issue, but basically, I'm getting significant performance degradation when writing directly to the response body stream, as opposed to just another stream. It's seriously affecting my download times, lowering them to 16-20 mb/s (I am serving files). Can anyone help me with this please?
https://stackoverflow.com/questions/76318014/asp-net-core-web-api-writing-to-response-body-is-insanely-slow
Stack Overflow
ASP.NET Core Web API : writing to response body is insanely slow?
I have an ASP.NET Core 7.0 Web API hosted on a server 2016 bare metal box. I'm creating dynamic ZipArchives and returning them when I receive API calls.
Generating a 300 MB ZipArchive from 800MB of
41 Replies
Unknown User•14mo ago
Message Not Public
Sign In & Join Server To View
Roger that
Unknown User•14mo ago
Message Not Public
Sign In & Join Server To View
No worries
Alright @vec![atreit; 1024]
Top is ziparchive -> memorystream -> responsebody
bottom is ziparchive -> responsebody
Winsock
That's on localhost too
It's weird that network negotiation would cause this kind of error
Let me find a way to hold the response until it's fully complete
Unknown User•14mo ago
Message Not Public
Sign In & Join Server To View
It's not I/O, I'm getting the ziparchive from memory
Only I/O happens on startup
Unknown User•14mo ago
Message Not Public
Sign In & Join Server To View
What do you mean?
It's a ziparchive
Unknown User•14mo ago
Message Not Public
Sign In & Join Server To View
responsebody writes something to disk temporarily?
network I/O is still I/O
Ah, I thought he meant disk i/o
Maybe if it's negotiating a lot of small data
That could be what's happening, each time I write to responsebody, I send a little data over the network
latency each time adds to the total
Hmm
Need a way to wait for the zip to be fully written to the response body before I release it to the client
I wonder what would happen to performance if I just ran this synchronous
Nothing, same story
Seems as soon as data is available in the response, the api fires it off
Hmm
Unknown User•14mo ago
Message Not Public
Sign In & Join Server To View
Not yet, let me do that now
Unknown User•14mo ago
Message Not Public
Sign In & Join Server To View
No worries
I'd need to go make a way to generate a ton of garbled zip data and stuff anyway, and that'll take me some time
Some progress
I'm awaiting on the memory stream to copy to the response body
and without network traffic it still takes 2 full minutes
I'm going to profile that and see what I get
Unknown User•14mo ago
Message Not Public
Sign In & Join Server To View
I'll grab it in a sec, right now it's crashing on localhost but not on remote for some reason
Unknown User•14mo ago
Message Not Public
Sign In & Join Server To View
I gotta fix this bug first
Interesting
On localhost I get a fatal exception, but running it remotely is fine
Cannot access a disposed resource
Unexpected exception in TimingPipeFlusher.FlushAsync.
Not much going on in the flame graph
Unknown User•14mo ago
Message Not Public
Sign In & Join Server To View
I mean you'd expect the deflate to take a while
Alright, debugged from the server end instead of localhost
This is for a networked request
Found it
It was a client bug
Dear god
Thanks for all the help guys ❤️
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.Alright
Wasn't a client bug, I think
Hard to say
I need to do some more benchmarking
Server seems to be slowing itself to the top speed of whatever client you use
Which is downloading slower off the wire than it should be
Narrowed it down a bit
tcp window isn't scaling to the request, it's doing something weird
Unknown User•14mo ago
Message Not Public
Sign In & Join Server To View
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.Wasn't 0 but it was low
There was a bunch of stuff going on
TCP window, MTU was too small
A lot of stuff that was both unrelated and related to the code
but I finally got it
11gb patch from france to dallas in 5 minutes
not bad
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.