Thanks Bert, have you seen the results:
https://www.appdynamics.com/blog/engineering/a-performance-analysis-of-python-wsgi-servers-part-2/
bjoern seems to be much more performant than the alternatives.
-alex
--
You received this message because you are subscribed to the Google Groups
"pylons-
It looks like bjoern is only single threaded, so can’t process concurrent
requests, and has no configuration besides host and port.
I wouldn’t sacrifice features for the sake of performance unless I had a
compelling reason to. The WSGI server is rarely a bottleneck.
You’ve been using Apache+mo
Also, a note on those performance benchmarks: They’re testing absurd numbers
of simultaneous connections. That might not be the most relevant metric.
Usually you put an HTTP server like nginx or HAProxy in front of your WSGI
server, which are very good at handling high-volume HTTP requests, s
On Thursday, September 12, 2019 at 1:54:53 PM UTC-4, Theron Luhn wrote:
>
> Usually you put an HTTP server like nginx or HAProxy in front of your WSGI
> server, which are very good at handling high-volume HTTP requests, so that
> your WSGI server isn't subjected to whatever the internet might
> * I've found a forking server like uwsgi / gunicorn to be the most
> performant strategy for most situations, as their "max_requests" settings
> to restart workers will eliminate most issues with process growth or memory
> leaks. they both also offer numerous deployment and management benefits
>
