|Re: [jetty-dev] Trying to make sense of slow server response times|
Thanks, Greg :)> If I'm understanding your benchmark correctly, the measureSumArrayHttp test is measuring average latency of:
Yes, this is correct. > So firstly, this is a really bad way to benchmark a server:Ok, but how can I benchmark a server without using (some) client code? And assuming I can't what kind of client code should I use instead? All I need to do is sent a GET request and receive the response (containing a single number).
> Given all that, you need to find out where the extra latency is coming from, with my two suspects being either the client itself or connection establishment time due to different reuse policies.
Yes, this is exactly my goal. However, I am pretty sure the client and connection establishment can only be one part of the story, because such client/connection establishment overhead would not depend on the size of the array (but the overhead does, it increases proportionally to the array size. at least for some of the machines I tried). I also used different profilers and logged the calculation time on the server side to verify that the vast majority of the measured time is actually spent on the array summation code.
> Enable the jetty stats handler and connection statistics and that will tell you latencies within the servlet and how many requests per connection etc.
Thanks for these suggestions. I will try the stats handler and log the connection statistics. Even though I don't think this can explain the cases where the overhead is proportional to the array size it might still be useful to understand those with the constant overhead.
On 09.05.22 12:19, Greg Wilkins wrote:
If I'm understanding your benchmark correctly, the measureSumArrayHttp test is measuring average latency of: - send a HTTP request via a client - jetty receives the HTTP request - the summation code runs in a servlet - jetty produces a response - the client receives the response So firstly, this is a really bad way to benchmark a server: - you will include time in client - you don't know the client and/or server connection reuse policy, so your latencies may also include connection establishment times - If you are concerned by throughput, then the rate requests are offered is a function of latency, which is not real world. - If the client is using a single connection, then you are likely to only be using a single CPU core on the server, so throughput will look less.... but then it won't be contending with other server threads for shared resources, so latency may be better Given all that, you need to find out where the extra latency is coming from, with my two suspects being either the client itself or connection establishment time due to different reuse policies. Enable the jetty stats handler and connection statistics and that will tell you latencies within the servlet and how many requests per connection etc. That will help you narrow down where the issue is. cheers On Sun, 8 May 2022 at 10:03, <easbar.mail@xxxxxxxxxx> wrote:Dear Jetty Devs and Community, hopefully I've come to the right place to ask for help with the following issue. I am puzzled by the server response times I am measuring using a Jetty instance. I reduced the issue such that now there are only two HttpServlets. One just returns a constant number and serves as a baseline. The other calculates and returns the sum of all integers in an array. I also measure the time the actual summation takes. On some machines everything seems fine: The response time of the servlet that does the summation is roughly equal to the time the summation is expected to take. Querying the server only adds a minimal overhead. But on others there is significant overhead (the servlet response is much slower than the actual summation), and on some the overhead is even proportional to the size of the array! You can find the benchmark, instructions how to run it and a more detailed explanation of my results (in README.md) here: https://github.com/easbar/jetty_jmh_benchmark/commit/f32ca12256021c69589a90f460097887ac802740. I am referencing to this specific commit to avoid confusion in case there will be changes to the benchmark later. I have tried using profilers and JVM flags like `-XX:+PrintCompilation` to find out what causes this slow down, but the server response times I am measuring still remain a complete mystery to me. They are very reproducible, i.e. whenever I run the benchmark I pretty much get the same result, but (qualitatively) different results for different machines. I also tried different JDK versions (8,11,17), and Jetty 9&11, but that does not seem to change anything. Frankly speaking I don't really know what else to try to get to the bottom of this, which is why I came here. Any kind of help would be highly appreciated, e.g. * running the benchmark and posting your results * looking at the results in README.md and giving some advice what I could do to debug this, or thinking about what *could* be the cause for such behavior Thanks in advance! _______________________________________________ jetty-dev mailing list jetty-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-dev_______________________________________________ jetty-dev mailing list jetty-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jetty-dev
Back to the top