Provide a reactor_resolver method that doesn't use reactor_pool/pthread #7
In my performance tests I have observed that after a
I assume the thread pool is used by
This could then be used by
Let me know if I should go ahead and create a PR to demonstrate this approach.
The text was updated successfully, but these errors were encountered:
Interesting as well. How you do measure performance increase, exactly? Yes, resolving without blocking is possible for example with AI_NUMERICHOST, we can do this transparently (and this has been done in other revisions). However that the mere presence of pthread has such a clear impact is interesting. I would like to try reproduce this.
Also you should be aware that libreactor and libdynamic are being refactored. The code as it is is likely to undergo fairly large changes, but regardless these potential overheads are definitely things I want to avoid.
As a side note, I do appreciate the contribution in the TechEmpower benchmark. However I do actually consider the use of preamble and such in the handler itself not to be a realistic approach. Of course this is up to the benchmark, and libreactor is just a framework, it is up to you how to use it. If the gain was clear enough it could maybe be done transparently as a "fast path" in the library, but the gain would need to be substantial.
Great, that's an even better idea!
I am running the code from the techempower json test on AWS in a cluster group using an m5.large for the server and a c5.2xlarge for the client.
I measure the performance using the same
Below is an example of a graph that shows the
Well it wouldn't have such a clear impact for most use cases, this test is definitely pushing the boundaries :). I just figure if we can get a little extra performance for free without impacting other use cases negatively then it is a win.
Great, sounds like the perfect time for feedback. I would be more than happy to test out some of the new code before the final release.
Yea I deliberately marked the default approach as a "platform" implementation and the reactor-server one as a "framework" implementation. I am not super happy with "preamble" either but I was in a bit of a hurry to squeeze out extra performance before the round 19 deadline and I saw that aspnetcore was using that approach. They even go a step further and precompute the response size, which I felt was probably too far.
I have it on my to-do list to revisit and measure the performance benefits more closely. From what I recall most of the benefit came from using a timer to only update the date once per second, but my implementation is definitely way too ugly. I will definitely let you know the results.
Oh, I should also mention I came across two resolver related issues while playing with the code. Let me know if you want me to create separate tickets for them.
Sigh, yes, I don't agree very well with this benchmark. Looking at the json serialization in aspnetcore I'm not sure if it's actually done dynamically for each request, and so forth. A decent way would perhaps be to have different candidates including a "low level" one that makes use of these kinds of optimizations.
I'll try to find some time to refactor this. Unfortunately time is something I have little of currently.