scieloorg / kernel

É o componente central da nova arquitetura de sistemas de informação da Metodologia SciELO, ainda em fase de desenvolvimento.
https://docs.google.com/document/d/14YBl7--4ouaWBQhxzUYWRuhmegwnSYrDgupsED6rhvM/edit?usp=sharing
BSD 2-Clause "Simplified" License
6 stars 11 forks source link

waitress ao invés de gunicorn na configuração de produção #151

Closed gustavofonseca closed 5 years ago

gustavofonseca commented 5 years ago

waitress é um webserver implementado integralmente em Python -- compatível com Python 2.7+ e 3.4+ --, projetado para ser utilizado em ambientes de produção.

Seu design usa uma abordagem mista entre async e sync: as conexões são aceitas de maneira assíncrona por um processo mestre, os dados são transferidos entre cliente e servidor de maneira assíncrona (dados armazenados em buffers) e em seguida as requisições são tratadas por workers síncronos. O tempo de serviço do worker síncrono é acelerado pelo fato de que todo IO entre cliente e servidor é realizado pelo componente assíncrono.

Há ainda um cenário envolvendo o uso de gunicorn em produção que pode levar a uma paralisia completa do sistema. O problema está descrito no link https://github.com/etianen/django-herokuapp/issues/9, copiado abaixo por motivo de preservação:

It's a bit subtle.

In order to use gunicorn as a frontend server, it needs to be used with async workers, such as those provided by gevent. Using the normal sync workers that are the gunicorn default can easily lead to thread starvation if several slow clients connect at once.

The issue with using the async gunicorn workers is that this leads to hundreds/thousands of requests being processed in parallel. The async gunicorn server can handle this fine, but the database server can easily choke in hundreds/thousands of concurrent connections from the async workers.

Waitress differs, in that it has an async master process that buffers the entire client body before passing it onto a sync worker. Thus, the server is resilient to slow clients, but is also guaranteed to process a maximum of (default) 4 requests at once. This saves the database from overload, and makes scaling services much more predictable.

Because waitress has no external dependencies, it also keeps the heroku slug size smaller.

On 27 February 2013 02:03, Saul Shanabrook notifications@github.com wrote:

What are the advantages of waitress over gunicorn? I couldn't find any
articles comparing the two.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-14151931

Outro ponto positivo no uso do waitress ao invés do gunicorn é que com ele o uso da lib prometheus_client é facilitado. Veja detalhes no link https://github.com/prometheus/client_python#multiprocess-mode-gunicorn