2015-05-09 16 views
10

Sto usando Gunicorn per servire un'applicazione Django, stava funzionando bene fino a quando ho cambiato il timeout da 30s a 900000s, dovevo farlo perché avevo un file in cui un enorme file doveva essere caricato e processati (processo che richiede più di 30m in alcuni casi) ma dopo questo cambiamento Gunicorn non risponde dopo poche ore, immagino che il problema siano tutti i lavoratori (essendo 30) saranno impegnati con alcune richieste dopo questo lasso di tempo, la cosa strana è succede anche se non eseguo quella lunga richiesta e succede con la normale esplorazione in admin di django. Voglio sapere se c'è un modo per monitorare le richieste su gunicorn e vedere i lavoratori sono occupati con le richieste, voglio scoprire le richieste che li rendono occupati. Ho provato --log-file=- --log-level=debug ma non dice nulla sulle richieste, ho bisogno di registri più dettagliati.Gunicorn non risponde

+0

La mia impressione è che potrebbe esserci un deadlock in alcuni dei codici di gestione delle richieste. Con un timeout di 30 secondi, i lavoratori interessati alla fine libereranno. Con un timeout di 0.9 megasecondi, in realtà non lo faranno. –

+0

Vedo, è per questo che ho bisogno di registri, per scoprire cosa sta succedendo. – Sassan

risposta

-1

Mentre cerco anche una buona risposta per vedere quanti lavoratori sono occupati, stai risolvendo questo problema nel modo sbagliato. Per un'attività che richiede tanto tempo è necessario un worker, come Celery/RabbitMQ, per eseguire il sollevamento pesante in modo asincrono, mentre il ciclo di richiesta/risposta rimane veloce.

Ho uno script sul mio sito che può prendere 5+ minuti per completare, ed ecco un buon motivo sto usando:

  1. Quando la richiesta viene prima in, deporre le uova del compito e semplicemente restituire un HTTP 202 accettato. Il suo scopo è "La richiesta è stata accettata per l'elaborazione, ma l'elaborazione non è stata completata."
  2. Chiedi al tuo front-end di eseguire lo stesso endpoint (ogni 30 secondi dovrebbe essere sufficiente). Finché l'attività non è completa, restituire un 202
  3. Eventualmente quando termina di restituire un 200, insieme a tutti i dati di cui potrebbe avere bisogno il front-end.

Per il mio sito, vogliamo aggiornare i dati che sono più vecchi di 10 minuti. Passo l'intestazione Accept-Datetime per indicare quanti anni di dati sono accettabili. Se la nostra copia cache locale è più vecchia di quella, generiamo il ciclo di attività.

+0

No, non è sempre una buona soluzione, "di solito" è giusto ma non sempre. A volte la logica è quella di far aspettare l'utente fino a quando la risposta è pronta (comunque ci vuole) e mostrargli la risposta.Nel mio caso avevo bisogno di farlo ed è per questo che l'ho chiesto qui (comunque non sono io quello che ha votato la tua risposta) – Sassan

+0

Ok, certo. Quello che ho proposto è solo di solito la risposta. Ma come "fai aspettare l'utente"? Cosa succede se colpiscono l'aggiornamento? Il lavoro continua o devono ricominciare. Se continua, come ottengono un aggiornamento di stato? – user3681414

+0

Ho appena creato un account con Datadog. Hanno un'integrazione con gunicorn che ti permetterà di vedere quanti lavoratori sono occupati e liberi. – user3681414