Gunicorn e Flask parlano attraverso WSGI, che ha due lati: lato server e lato applicazione.
sul lato applicazione (framework), abbiamo bisogno di fornire un callable, l'esempio più semplice:
def application(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return ['Hello World']
server chiamerà questa applicazione e di fornire informazioni sull'ambiente e di una funzione di callback che viene utilizzato per indicare inizio di una risposta. quando il server ottiene la risposta, la restituirà al browser.
così, per gunicorn e pallone:
from flask import Flask
app = Flask(__name__)
quando si esegue questa operazione, hai effettivamente ottenuto un'applicazione compatibile con WSGI, app
è un callable:
class Flask(object):
...
def __call__(self, environ, start_response):
"""Shortcut for :attr:`wsgi_app`."""
return self.wsgi_app(environ, start_response)
[source](https://github.com/mitsuhiko/flask/blob/master/flask/app.py#L1976)
e quando si esegue gunicorn app:app
, stai dicendo a gunicorn dove caricare la tua domanda, source
quando arriva una richiesta, gunicorn lo analizza, costruisca un dict environ
, che è definita here, contiene informazioni come REQUEST_METHOD
, QUERY_STRING
ecc, quindi chiamare l'applicazione (un oggetto Flask!) Con esso: app(environ, start_repsonse)
source, start_repsonse
è un callback in Gunicorn per ottenere lo stato reponse e le intestazioni, e il valore di ritorno di la chiamata app
verrà inviata come corpo della risposta.
Qual è la differenza tra la chiamata di app.run() e la chiamata all'applicazione di flask tramite Gunicorn? – neel
'app.run()' eseguirà l'applicazione con il server wsgi integrato del pallone, che è destinato allo sviluppo e funziona male con un carico elevato. mentre gunicorn è altamente ottimizzato per le prestazioni – wong2
gunicorn python_file: l'app indicherà a gunicorn dove caricare la tua applicazione. Cosa significa? Puoi spiegarlo ancora un po '? – neel