Risposte:
flask.Flask.runaccetta argomenti di parole chiave aggiuntive ( **options) che inoltra a werkzeug.serving.run_simple- due di questi argomenti sono threaded(un valore booleano) e processes(che è possibile impostare su un numero maggiore di uno per far sì che werkzeug generi più di un processo per gestire le richieste).
threadedil valore predefinito è TrueFlask 1.0, quindi per le ultime versioni di Flask, il server di sviluppo predefinito sarà in grado di servire più client contemporaneamente per impostazione predefinita. Per le versioni precedenti di Flask, è possibile passare esplicitamente threaded=Trueper abilitare questo comportamento.
Ad esempio, puoi farlo
if __name__ == '__main__':
app.run(threaded=True)
gestire più client usando i thread in modo compatibile con le versioni precedenti di Flask, oppure
if __name__ == '__main__':
app.run(threaded=False, processes=3)
per dire a Werkzeug di generare tre processi per gestire le richieste in arrivo, o semplicemente
if __name__ == '__main__':
app.run()
per gestire più client usando i thread se sai che utilizzerai Flask 1.0 o versioni successive.
Detto questo, Werkzeug racchiude serving.run_simpleil wsgirefpacchetto della libreria standard e quel pacchetto contiene un'implementazione di riferimento di WSGI, non un server Web pronto per la produzione. Se stai per usare Flask in produzione (supponendo che "produzione" non sia un'applicazione interna a basso traffico con non più di 10 utenti simultanei) assicurati di sostenerlo dietro un vero server web (vedi la sezione dei documenti di Flask intitolata Opzioni di distribuzione per alcuni metodi suggeriti).
L'uso del semplice app.run()dall'interno di Flask crea un singolo server sincrono su un singolo thread in grado di servire solo un client alla volta. È destinato all'uso in ambienti controllati a bassa richiesta (ad es. Sviluppo, debug) proprio per questo motivo.
Generare thread e gestirli da soli probabilmente non ti porterà molto lontano, a causa di Python GIL .
Detto questo, hai ancora alcune buone opzioni. Gunicorn è un server WSGI solido e facile da usare che ti consentirà di generare più lavoratori (processi separati, quindi non preoccuparti di GIL) e persino di lavoratori asincroni che accelereranno la tua app (e la renderanno più sicura) con poco a nessun lavoro da parte tua (specialmente con Flask).
Tuttavia, anche Gunicorn probabilmente non dovrebbe essere esposto pubblicamente direttamente. In produzione, dovrebbe essere utilizzato dietro un server HTTP più robusto; nginx tende ad andare bene con Gunicorn e Flask.
gunicorn app:app 127.0.0.1:8080anziché python app.py. Nginx fungerebbe da servizio pubblico che espone la tua app privata Gunicorn (un proxy inverso) , nascondendo tutti i tipi di dettagli di implementazione HTTP di livello inferiore, magari servendo direttamente i file statici, ecc.
processes=100ed essere felice con esso? Nel mio caso, ho solo bisogno di file statici, senza metodi Post HTTP. Il mio requisito è che voglio eseguire tutti i thread Flask come parte della mia app padre, in modo che tutti possano condividere le variabili.