Re: HTTP frameworks benchmark focused on D libraries
Hi all, I've just pushed the updated results. Test suite modifications: * added runner command to list available tests * possibility to switch off keepalive connections - causes `hey` to make a new connection for each request * added parameter to run each test multiple times and choose the best result out of the runs Tests additions: * new RAW tests in C to utilize epoll and io_uring (using liburing) event loops - so we have some ground base we can compare against * same RAW tests but in Dlang too - both in betterC, epoll is basically the same, io_uring differs in that it uses my during[1] library - so we can see if there are some performance problems (as it should perform basically the same as C variant) Some insights: I've found the test results from hey[2] pretty inconsistent (run locally or over the network). That's the reason I've added the `bestof` switch to the runner. And the current test results are the best of 10 runs for each of them. Some results are a bit surprising, ie that even with 10 runs there are tests that are faster than C/dlang raw tests - as they should be at the top because they really don't do anything with HTTP handling.. And eventcore/fibers to beat raw C epoll loop with fibers overhead? It just seems odd.. I'll probably add wrk[3] load generator too to see a difference with a longer running tests. [1] https://github.com/tchaloupka/during [2] https://github.com/rakyll/hey [3] https://github.com/wg/wrk
Re: HTTP frameworks benchmark focused on D libraries
On Sunday, 27 September 2020 at 10:08:24 UTC, tchaloupka wrote: Hi all, I've just pushed the updated results. * new RAW tests in C to utilize epoll and io_uring (using liburing) event loops - so we have some ground base we can I'll probably add wrk[3] load generator too to see a difference with a longer running tests. [1] https://github.com/tchaloupka/during [2] https://github.com/rakyll/hey [3] https://github.com/wg/wrk Thank for this job. It may be worth to add nginx as baseline for real C-based server. I'll add my framework as soon as it will be ready.
Re: beerconf September!
On Sunday, 27 September 2020 at 00:48:34 UTC, Steven Schveighoffer wrote: Here is day 1's notes. https://gist.github.com/schveiguy/ba5532fa64822113a8877ae4be37eeeb Beer thread! Where are the worst beers created? We have some contenders: Ethan: Finland I also followed on and said Finnish beers are a shadow of the trash that comes out of Australia. Craft brewers in both countries do some good stuff though, but anything exported is going to be mass produced junk. This is beerconf. Get the beer talk right jeez.
Re: HTTP frameworks benchmark focused on D libraries
I fixed my event loop last night so I'll prolly release that at some point after a lil more testing, it fixes my keep-alive numbers... but harms the others so I wanna see if I can maintain those too.
Re: Release D 2.094.0
On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. I'd use the delay as an opportunity to shift the bi-monthly releases to even months (to avoid the beta during the holiday season). https://github.com/dlang/dlang.org/pull/2860
Re: Release D 2.094.0
On Saturday, 26 September 2020 at 22:12:17 UTC, Imperatorn wrote: On Saturday, 26 September 2020 at 21:45:09 UTC, Martin Nowak wrote: Glad to announce D 2.094.0, ♥ to the 49 contributors. This release comes with faster compiler binaries (built with ldc), direct git dependencies in dub, better type checking of vectors, and improved template instantiation diagnostics. http://dlang.org/download.html http://dlang.org/changelog/2.094.0.html -Martin Hurrah! 🌈🍀 Yay! "-preview=in" is beyond epic!
Re: HTTP frameworks benchmark focused on D libraries
On Sunday, 27 September 2020 at 10:08:24 UTC, tchaloupka wrote: * new RAW tests in C to utilize epoll and io_uring (using liburing) event loops - so we have some ground base we can compare against I fixed some buffering issues in cgi.d and, if you have the right concurrency level that happens to align with the number of worker processes... I'm getting incredible results. 65k rps. It *might* just beat the raw there. The kernel does a really good job. Of course, it still will make other connections wait forever... but my new event loop in threads mode is now also giving me a pretty solid 26k rps on random concurrency levels with the buffering fix. I just need to finish testing this to get some confidence before I push live but here it is on a github branch if you're curious to look: https://github.com/adamdruppe/arsd/blob/cgi_preview/cgi.d Compile with `-version=embedded_httpd_threads -version=cgi_use_fiber` to opt into the new event loop. But the buffering improvements should register in all usage modes.
Re: beerconf September!
On 9/27/20 8:14 AM, Ethan wrote: On Sunday, 27 September 2020 at 00:48:34 UTC, Steven Schveighoffer wrote: Here is day 1's notes. https://gist.github.com/schveiguy/ba5532fa64822113a8877ae4be37eeeb Beer thread! Where are the worst beers created? We have some contenders: Ethan: Finland I also followed on and said Finnish beers are a shadow of the trash that comes out of Australia. Craft brewers in both countries do some good stuff though, but anything exported is going to be mass produced junk. This is beerconf. Get the beer talk right jeez. It was a collaborative document. If you don't like my partially inebriated experience report, you are free to add your own. I'm not a court stenographer, I can't be expected to record every word everyone says. -Steve
Re: HTTP frameworks benchmark focused on D libraries
On 9/27/20 6:08 AM, tchaloupka wrote: Hi all, I've just pushed the updated results. Thanks for continuing to work on this! vibe-core performs quite well -- scaling up with additional workers from 8 through 256, whereas vibe-d platform tops out around ~35,000-45,000 RPS irrespective of simultaneous workers (plateauing between 8-64 workers). Given the outstanding performance of vibe-core it looks like there is room to continue to improve the vibe-d platform. Cheers again for your work.
