I added scalatra (scalatra 2.4.1 on embedded jetty) to tests set. Two testing tools from three (ab and weighttp) give me approximately the same results for all three frameworks in ~70MB/s throughput when I test long static result. So it is similar to network bandwidth saturation. On the other hand in case of scalatra wrk is able to get to 86MB/s and iperf from client to server with default parameters can give me ~88MB/s.
Can it be networking problem? How do I check it? Code can be found at https://gist.github.com/olga-gorun/825e823027aadb2962b3b7229e4d5d48 Tests results - https://docs.google.com/spreadsheets/d/1yuFD7WDOzhWB5_Ob7XgAfFAdWt48SrthbvZSZ45GE-k/edit?usp=sharing On Thursday, October 6, 2016 at 10:42:04 PM UTC+3, Olga Gorun wrote: > > For more information, I give here versions I test with. > > ubuntu 14.04, scala 2.11.8, oracle jdk 1.8 > > akka-http: 2.4.11 > > spray: 1.3.1 with akka 2.3.6 > > On Thursday, October 6, 2016 at 10:26:48 PM UTC+3, Olga Gorun wrote: >> >> Hi Christian. Thank you for response. I checked that equal Xms/Xmx both >> set to more than enough memory (4GB while used heap is not more than 1.5GB >> during load test with or without explicitly defined memory) don't >> influence results. I'll try other JVM settings you propose. But generally >> speaking I don't understand why I should see something different in GC >> behavior. String used as response defined as val in object. It's not >> created in some class instantiated per request. So GC should not clear it. >> When GC should make more work if response length is increased? >> >> On Thursday, October 6, 2016 at 10:03:47 PM UTC+3, Christian Schmitt >> wrote: >>> >>> garbadge collection I guess. also I didn't see if you've set Xms/Xmx you >>> should set them equal. And also try the following: -XX:+UseNUMA >>> -XX:+UseG1GC -XX:+AlwaysPreTouch -XX:+PerfDisableSharedMem >>> -XX:+ParallelRefProcEnabled paramters, not all of them will be helpful, but >>> you should try some of them. >>> >>> Am Donnerstag, 6. Oktober 2016 18:08:57 UTC+2 schrieb Olga Gorun: >>>> >>>> I continue playing with given example projects and see strange results. >>>> If I increase string length of static response from 7 to 2490 characters >>>> throughput is reduced to ~24K rps for both spray and akka-http. >>>> Does anybody else see such results? How can they be explained? >>>> >>>> >>>> >>>> On Wednesday, October 5, 2016 at 8:47:54 AM UTC+3, rkuhn wrote: >>>>> >>>>> Hi Olga, >>>>> >>>>> establishing a connection is a very expensive operation, which is why >>>>> all modern clients/browsers reuse them for multiple requests. The ab tool >>>>> needs the -k switch to enable this behavior. >>>>> >>>>> Regards, Roland >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On 5 Oct 2016, at 01:32, Olga Gorun <ogo...@gmail.com> wrote: >>>>> >>>>> >>>>> I tried to repeat this benchmark and would be glad to see comments to >>>>> results I got. >>>>> Tested porjects: gists from original post with the following versions: >>>>> >>>>> akka-http, 2.4.11 vs spray, 1.3.1 (akka - 2.3.6). In both cases scala >>>>> 2.11.8, jvm 8. >>>>> >>>>> The tests were done on AWS machine of c4.2xlarge type (8 cores CPU, >>>>> 16GB memory, ulimit - 500000). As I can see from jvm and system >>>>> monitoring, >>>>> it is far from being limited by CPU, memory, disk IO or networking. OS: >>>>> Ubuntu 14.04 >>>>> >>>>> See results at: >>>>> https://docs.google.com/spreadsheets/d/1yuFD7WDOzhWB5_Ob7XgAfFAdWt48SrthbvZSZ45GE-k/edit?usp=sharing >>>>> >>>>> Starting from the fact that my results are different (spray gives >>>>> better results than akka-http). In addition I see interesting effects >>>>> when >>>>> I use different benchmark tools. I also started from wrk, but in addition >>>>> to throughput I wanted to see failures if exist, and latency percentiles, >>>>> so I added tests with weighttp and ab. >>>>> >>>>> Throughput reported by ab is much different than the rest and shows >>>>> drastic difference between akka-http and spray. Reported latency also >>>>> don't >>>>> have much in common. I can think that ab (as a single-threaded tool) can >>>>> be >>>>> bottleneck itself. But how to explain such a difference in throughput for >>>>> akka-htttp and spray? And how to explain difference in reported latency. >>>>> >>>>> Regards, >>>>> Olga Gorun >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>>>>>>> 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+...@googlegroups.com. >>>>> To post to this group, send email to akka...@googlegroups.com. >>>>> Visit this group at https://groups.google.com/group/akka-user. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> -- >>>>>>>>>> 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.
