Thank you Johannes for your comments. As you pointed out, the 40 core machine isn't a typical hardware, we chose it just for measurement purposes and were quite surprised by the results. We've been using for quite a while a home-grown server built on top of Netty which works pretty well for us, but time to time we consider switching for something 'more standard', and often Akka is being mention. I've been following Akka for many years I must say I'm really impressed by the project, you guys have done amazing work. I had used Spray before and was impatiently waiting for Akka Http, so when it finally got out and was being said to be on pair, or faster, with Spray, I couldn't wait to try it out. The test itself was actually done by colleagues of mine, and after finding out that Akka Http didn't performed very well I was kind of also blaming them that they didn't set it up correctly and was myself trying out every possible settings, including parallelism-factor = 1 and parallelism-max = 40, changing dispatchers etc. to persuade them that Akka Http can defeat other JVM based servers and was eventually sad that I was not able to achieve it. That's why I've created this post and included the benchmark code so that others, or your team, can help me to find out what needs to be tweaked to make Akka Http shining again.
Jakub On Monday, November 13, 2017 at 1:46:13 PM UTC+1, johannes...@lightbend.com wrote: > > I missed this post before. > > I'd like to add another point. Akka Http hasn't been performance tested on > a 40 core machine. The high idle CPU percecntage means that either Akka / > Akka Http is not configured correctly for this amount of cores or that > there are actual contention issues at these levels of scale. It would be > definitely interesting to know what the problem is to offer a better > default experience for running Akka Http on this kind of hardware. > > If you are still listening in, Jakub, it would be nice if you could set > parallelism-max to the number of cores on your machine and/or set > `parallelism-factor = 1` as Patrik suggested. One reason for bad > performance could be that the default parallelism-factor of 3 would lead to > 120 threads battling for resources, starving each other off CPU time maybe > even while keeping some resource. If this alone doesn't increase > performance, a few stack dumps from the server process during steady state > would help because that would likely point out places with high contention. > > For anyone else listening in here, I also wanted to stress, that you need > to put any kind of performance numbers into perspective. We cannot test > everything in every environment and details usually matter in benchmarks. > High CPU idle times like in this case mean that something currently just > doesn't work correctly in this setting. For best performance, you need to > benchmark for yourself on your own hardware and then be prepared to dig > into issues. > > Johannes > >> -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
