Pattern per richieste con tempi di risposta lunghi?

Question

Pattern per richieste con tempi di risposta lunghi?

#1 da (5 voti)
#2 da (2 voti)
#3 da (1 voti)

6

Al momento stiamo mantenendo un "server web" pitone nativo dove generare la risposta per alcune richieste può richiedere molto tempo, soprattutto a causa di calcoli pesanti: queste richieste sono essenzialmente post con timeout molto lunghi (si pensi ai minuti a decine di minuti) .

Un problema di questa architettura è che a volte c'è la necessità di citare una tale richiesta - ad es. l'utente ha notato un errore durante la configurazione della richiesta. Attualmente, l'annullamento è un'altra richiesta, che annulla la richiesta di lunga durata - ma ci sono molte lacune, e. g. cosa succede se il client chiude semplicemente il sito web?

Attualmente, stiamo pianificando di ritirare l'abominio locale di un server web e passare a qualcosa di sensato - e. g. Flask che funziona all'interno di un IIS usando wfastcgi. Per ragioni politiche, IIS è impostato, quindi passare a qualcosa come gunicern è fuori dalla finestra.

Tutti gli sviluppi si sono fermati su questo perché nobdy ha un'idea, come uccidere i processi eseguiti da (w) fastcgi - questa preoccupazione non è semplicemente parte delle specifiche fastcgi.

La mia sensazione è che un tentativo di costruire qualcosa che incorpori sia un errore - preferirei una soluzione in cui il server scarichi semplicemente tali compiti di calcolo intensivo su qualche server in background (flask + sedano?) e i sondaggi di frontend per quello .

Sfortunatamente, la vecchia soluzione era in vigore da così tanto tempo che alcuni sviluppatori vogliono mantenere il comportamento a tutti i costi.

Non essendo un ragazzo di server weber, mi piacerebbe avere alcuni tipp / modelli su come potrebbero essere le soluzioni sensate per un simile problema.

python

posta Christian Sauer 20.02.2016 - 16:38

fonte

3 risposte

Leggi altre domande sui tag python

Cosa fare con i miei test di unità durante il refactoring del codice in una nuova classe Perché la dimensione della squadra non influisce sul tempo di scrum-boxing per le riunioni?

score 5 · Answer 1

Ciò che stai suggerendo è giusto.

Dovrebbe essere asincrono.

Puoi pubblicare una richiesta e la richiesta ti dà un ID unico. Pubblica un Fatto su questo ID univoco in qualche negozio in cui puoi effettuare il polling.

Se hai bisogno di cancellare una richiesta, deve essere pubblicata una richiesta di cancellazione usando lo stesso Id

Anche nel back-end dove questi calcoli sono in esecuzione, ad esempio in un'interfaccia di esecuzione di un Thread (stile java), è possibile controllare dopo ogni secondo se il processo viene annullato controllando se è stato richiesto un post di annullamento. Se lo è, allora il thread deve uscire. Questa è un'uscita pulita. Puoi anche usare un'interruzione alla discussione.

score 2 · Answer 2

Ti suggerisco di esaminare wsgi e utilizzare multithreading . È possibile gestire ogni richiesta in un thread e implementare i timeout nel thread. Dovresti anche essere in grado di gestire i thread e cancellare le richieste più facilmente.

score 1 · Answer 3

Il problema con cui ti trovi attualmente con un semplice post HTTP non può essere risolto in quel protocollo. HTTP funziona in modo asincrono in client / server severi, quindi non vi è alcuna notifica sul lato server e nessun annullamento nativo. Inoltre, dovrai affrontare il problema delle risposte perse a causa dei timeout della rete internet. Suggerirò un approccio diverso e moderno. Dichiarazione di non responsabilità: supporto browser meno del 90%

Suggerirei di invertire il flusso di informazioni e utilizzare websocket. Quello che devi fare una volta che un compito è fatto è notificare all'utente e spingere una notifica dal server al client.

Quando un compito viene pubblicato, o, più esattamente, come sostituto del post, apri un websocket (usa la tecnologia server che ti piace, tornado, gevent, python-websocket ecc.). Associare il thread dell'attività sull'evento open websserver del server. Se il client si chiude, il client invierà un evento close al gestore websocket, in modo che tu possa terminare il thread ad esso associato. Altrimenti, se l'attività termina normalmente, il server può inviare i dati al client e chiudere il web socket. Inoltre, devi fare il ping del server una volta ogni 30 s perché i websocket si chiudono se inattivo per più di un minuto.

Se lo applichi, questo sarà il più veloce e più pulito di un sondaggio sul lato client, mentre risolverai problemi di gap poiché hai un vero canale bidirezionale. Si noti che è possibile implementare servizi aggiuntivi sullo schema delle attività come sessioni, ping di avanzamento ecc.