-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ASP.NET Schedulers #84
Comments
For For For |
This
ok, I will consider it unsafe to use There is another use of ThreadPool not mentioned yet. The Handler gets put on ThreadPool by KestrelConnection class (see stacktrace below of JSON middleware). Though I assume that doesn't make it safe to set i=inline? Do you recall the rationale for running the handler on ThreadPool? Is this also happening for JSON platform benchmark?
Yes, benchmarks we ran showed the same thing, though it's hard to understand why.
|
I figured out this isn't safe. The stacktrace changes for successive requests on the same connection. Do you recall the rationale for running the handler on ThreadPool? |
I think I got this too. If there is already a request in the input pipe the request handling would start, and stops Kestrel from accepting more connections until the handling goes async. It reduces kestrels accept connections per second performance.
I guess so. It doesn't matter much for the TE benchmarks, it only affects the first request from a connection. |
Adding some graphs from benchmarks. Using threadpool
(x-axis is nr of epoll threads from 0 to ProcessorCount, I cut off the values because excel webview renders them wrong in chrome) Since epoll threads don't do much work, we don't need many of them. Here IoQueue has better performance than Inline. Using epoll threads
Since epoll threads do much work, we need a lot of them. Here IoQueue reduces worse than Inline. Other@antonfirsov and I discussed running benchmarks also for this combination:
It would be meaningful also in light of previous discussion because this could be used safely by Kestrel even when user may have blocking handlers. |
That would be an ideal option IMO for kestrel and it should be opt-in at the socket level |
It looks like you answered all of your own questions @tmds 😄. I agree an option to enable the inline scheduling of app code (i.e. ApplicationSchedulingMode) is something we should add back as a SocketTransportOption. I'll look into this. |
That makes sense. IIRC, the reason we run Socket.ReceiveAsync continuations inline on linux, but not Windows, is because on linux the continuation is already dispatched to a threadpool thread, whereas on Windows we're still on an I/O thread.
Agreed. As long as we're not calling into non-framework code it should be safe to inline. |
@halter73 Is combination of |
Yes. Running continuations inline is safe if all they do is write to a PipeWriter and the reader scheduler is set to the threadpool. |
@tmds @halter73: Explanation of labels:
Note: I did run this on |
Combining with results from #78 (comment), and taking best results for
Config 1 is most similar to the current behavior. Some thoughts about
edit: added |
The gain we get in config 2 is thanks to using AIO. |
@kouvel might be able to answer this question |
Yes I think that would be feasible and would be a better option than having another pool of threads, but it may have some tradeoffs, would have to try it out. |
I misunderstood and thought there was another pool of threads. I did some experiments relevant to using the thread pool directly instead of the IOQueue, so far I have not seen the thread pool performing better. It seems there is benefit from batching and maybe other things. I have posted some more info in our Teams channel. Based on the info I have so far it does not appear to be feasible to remove the IOQueue by using the thread pool instead. |
@davidfowl @halter73 we've added control over the schedulers that get used.
We can control these:
c
: where do async socket continuations run: inline/threadpooli
: input pipe reader scheduler: inline/threadpoolo
: output pipe reader scheduler: inline/threadpool/ioqueue/iothreadThe bold values are the default.
When we inline all these scheduler and use ProcessorCount threads, we measured 1m rps for middleware JSON on Citrine.
I wonder which of these would be safe to
inline
in a production app, where there may be potentially blocking code from the user?I guess this would be
c
(because the application code is decoupled to ThreadPool later) and alsoo
(because the application code runs on the output pipe writer scheduler). Is that correct?What about
i
?cc @antonfirsov @adamsitnik
The text was updated successfully, but these errors were encountered: