Richieste a esecuzione automatica con terminazione automatica in Django

Ho una configurazione con Apache + mod_wsgi che esegue il codice django e vorrei aggiungere un livello di protezione nel caso in cui una vista non terminante scivoli dentro. Qualcosa che uccide -da una richiesta superiore a, diciamo, 30 secondi sarebbe l'ideale.Richieste a esecuzione automatica con terminazione automatica in Django

Per il test ho appena inserito un time.sleep(60) in una vista.

Ho provato l'impostazione TimeOut 30 in Apache, ma continuo ad arricciare il ritorno dopo 60 secondi.

Vedo che mod_wsgi offre tre diversi valori di timeout, ma nessuno di essi sembra essere applicabile a una richiesta di lunga durata.

C'è un pezzo standard del middleware Django per questo o c'è una manopola che mi manca su Apache o mod_wsgi?

fonte

2011-10-11 Ry4an Brase

In realtà è davvero difficile terminare un singolo thread di richiesta Python in un'applicazione multithread. Il meglio che puoi fare è prendere la decisione di arrestare l'intero processo e riavviarlo. Poiché una tale azione interromperà le richieste concorrenti, avresti davvero bisogno di limitarti a una singola configurazione con thread.

Anche in questo caso il supporto in mod_wsgi 3.X non è ideale per questo. Esiste un timeout di inattività per la modalità daemon, ma in realtà causa il riavvio del processo in due situazioni. Il primo è quando non ci sono richieste e il processo è inattivo. Il secondo è quando tutti i thread di richiesta sono bloccati e il timeout scade.

In mod_wsgi 4.X (nel trunk del repository in questo momento), i due concetti sono stati separati e ora inactivity-timeout si applica solo al processo completamente inattivo senza richieste simultanee. Un nuovo timeout bloccato è stato aggiunto a un timeout specifico per quando l'intero processo è bloccato. È quest'ultimo che puoi usare.

Se vuoi saperne di più sulla nuova opzione, devi passare alla mailing list mod_wsgi per discuterne.

fonte

2011-10-11 21:25:59

Grazie. Una cosa che abbiamo cercato di fare era passare da, diciamo 5 processi con venti thread di richiesta ciascuno, a 100 processi con un thread di richiesta ciascuno. La speranza è che i timeout di mod_wsgi possano poi uccidere i processi senza danneggiare le richieste non correlate. In pratica questo non ha funzionato per motivi di memoria di sistema (mi sarei aspettato più memoria condivisa), ma è possibile che mod_wsgi possa uccidere quel processo se i trigger di inattività-timeout? –

L'applicazione viene caricata dopo il fork, quindi nulla è condiviso in modo tale che la copia su scrittura sarebbe un vantaggio. Il vantaggio del precaricamento prima della forking in Python non è tanto quanto le persone potrebbero pensare che l'esecuzione del codice manipola il conteggio dei riferimenti e quindi la copia viene eseguita sulla maggior parte delle cose in qualsiasi modo. –

L'opzione di timeout bloccato in mod_wsgi 4.0 è probabilmente ancora la scelta migliore. Puoi ancora eseguire multithreading e si avvierà quando tutti i thread saranno bloccati. Aspettare fino a quando tutti i thread bloccati anche se non va bene. Quindi c'è anche un'impostazione delle richieste bloccate. Se hai thread = 15, puoi dire block-requests = 5. Quindi, non appena vengono bloccati cinque thread e raggiunge il punto in cui nessuna richiesta viene gestita dal processo, quindi eseguirà un riavvio sicuro. Essere in grado di impostare la soglia delle richieste bloccate ti dà un margine di sicurezza, quindi il processo non si impantana. –

Richieste a esecuzione automatica con terminazione automatica in Django

risposta

Problemi correlati