Bad performance (Django REST API, WSGI)

[mike667]

Hello, I was very happy when I saw the benchmarks.

Provide stable performance when compared to existing alternatives

I tried it on my real project. The project is written in Django, using WSGI. My benchmark simulates user behavior on my website using a k6 script. I conducted a test with the same number of users for both gunicorn and granian.

It turned out that the requests per second are the same or worse than with gunicorn. The p95 response time with gunicorn is better. I tried different configurations of threads/workers per 1 CPU, tried with --opt / --no-opt. The result is always worse or close to gunicorn. The best result I currently achieve is by running one process per CPU for both gunicorn and granian. (The project runs on Kubernetes across three nodes with 8 CPUs each)

For me, the goal was to achieve at least a 0.5% improvement or to use fewer resources. I understand that this is just a web server and it's not the bottleneck of the system.

Do you have any ideas on what I might be doing wrong?
Thank you

[gi0baro]

Hi @mike667, I'm sorry to hear that.
So, in general the final performance is really dependant on your application code, as Granian can only affect the network part of that: there's no dark magic to apply here, Granian is still subject to GIL and blocking code whenever it interacts with your application.

Now, given this, here are a few considerations:

• I expect you run Gunicorn using gevent workers, is that correct? Granian implementation is very similar to gevent, so the performance at the end should be statistically comparable.
• opt only affects ASGI and RSGI protocol, as those are event-loops optimizations and WSGI is a syncronous protocol (no event-loop involved at all)
• I would suggest you to play a bit with --threads and --blocking-threads numbers, as they might help increasing RPS for certain applications. Also, testing the behaviour with both workers and runtime threading modes can produce different results.
• Does your application consumes/produce large bodies? If so, this is something that might still need some optimization in Granian with WSGI protocol in the future
• Usually when it comes to kubernetes, I tend to stick with 1 process per pod and 1 or 2 threads/blocking threads combination, spawning more pods to effectively use more cpu rather than increasing the number of processes. This might help as well

[mike667]

@gi0baro Thanks for the advice!