Stress server project - Clojure web servers profiling

Hello everyone,

I would like to share with you a project I have been working on in the past few weeks, stress-servers, aimed at setting up reproducible stress testing and profiling environments for Clojure servers.

It’s an ongoing project with the goal of finding the best configurations and settings, understanding the effects of JVM versions and GC algorithms, identifying performance bottlenecks and in general, learn!

I hope you can find interesting and useful bits in it. It should help inform developers when choosing libraries and setting up servers, and library developers on the effects of their design choices.

Contributions and feedback are very welcome. We can push the ecosystem forward.

This project has been in the works for a long time and I’m happy to finally be able to share it
(and apologize if the cross-posting has been spammy)

Cheers

5 Likes

Very interesting, and awesome to see http-kit doing so well.

What was the memory on the machine? And when request times slowed down, was the memory reaching the max available or was it all CPU bound?

1 Like

I didn’t profile memory usage besides the particular case where I was looking for the memory leak in Aleph. Memory was the default configuration for the JVM. My idea was to use the defaults as a baseline as much as possible, partly to show that even a relatively naive usage can give pretty good results.
I was also surprised to see http-kit come out on top. I’m not able to adequately explain all the results, yet, and I hope some library authors will blow up my issues with “you’re using it wrong!”
Either that or they’ll look at the profiling results and find something to fix.

1 Like

I think you are running into this issue with the Aleph memory leak. Using Aleph with the default Reitit settings under load will result in heap exhaustion (though I’ve not tested with the most recent alpha releases). Using the :return :bytes option in Muuntaja does fix it.

2 Likes