-
-
Notifications
You must be signed in to change notification settings - Fork 115
EngineCutelystWSGI
After many performance improvements on Cutelyst a component that seemed to be limiting performance was uWSGI. As an experiment Cutelyst-WSGI was born to try to fill the design issues that integrating with uWSGI had:
Benchmarking without Keep-Alive got to a place that was hitting TCP stack, getting more than 40k req/s was looking impossible, our implementation allowed for overcoming this limit getting to 100k req/s using a single thread.
This issue hits all protocols HTTP 1.1 (Keep-Alive) is only available in uWSGI 2.1 (which till now 2017-03) has no plans to be release, FastCGI implementation also doesn't support Keep-Alive and last uwsgi protocol doesn't support this too.
When benchmarking with NGINX in front of Cutelyst-WSGI be using HTTP or FastCGI the Keep-Alive shows for a considerable amount of improvement.
Starting a process with 100MB just because you might have some high number of concurrent clients connected seemed an overkill, our implementation allocates memory for each new request as the get in, this happens very fast and there are other kinds of improvements that can make less important things faster.
Forking uWSGI with 1000 workers used more than 1GB of RAM and 10 seconds to be ready, Cutelyst-WSGI uses less than 300MB and around 3 seconds. You can already see the savings in your cloud provider or using the extra memory for some caching.
While uWSGI can run on Windows compiled with mingw, Cutelyst-WSGI uses Qt classes which puts it in every platform supported by Qt, faster, and more efficiently.