Perché la pagina del tuo sito aspetta un lavoro lungo

Se la pagina che il visitatore aspetta spedisce anche una mail, ridimensiona un'immagine o chiama un servizio lento, la domanda è se quel lavoro resta dentro la richiesta. Il 3 novembre 2026 ho letto la pagina sulla concorrenza aggiornata nel 2017, due pagine del manuale PHP, due moduli di nginx e la pagina MDN sullo stato 504. Non dicono la stessa cosa. Non ho misurato un sito e non ho spostato un lavoro.

La pagina del 2017

La pagina The Twelve-Factor App, fattore Concurrency, scrive Last updated 2017. In fondo il copyright è 2026, Salesforce. Nella risposta letta il 3 novembre 2026 non c'è last-modified. Le due date non coincidono. Non le unisco.

Dice che le richieste HTTP possono essere gestite da un processo web, e i compiti lunghi in background da un processo di lavoro. È un può. Non è un obbligo. La stessa pagina dice che questo non esclude, dentro un singolo processo, i thread oppure il modello asincrono. Gli esempi di quel modello sono EventMachine, Twisted e Node.js. Il processo di lavoro e il modello asincrono restano due frasi. Non li unisco.

L'esempio sui processi PHP li descrive come figli del server web, avviati secondo quante richieste arrivano. I processi Java, nella stessa pagina, stanno all'opposto: un solo processo grande che riserva risorse all'avvio, e la concorrenza è interna, a thread. Non sono la frase sul processo di lavoro.

Più avanti scrive che un processo singolo può crescere solo fino a un certo punto, e che l'applicazione deve poter stare su più processi e più macchine. Aggiungere concorrenza, in quel modello, è aggiungere processi. Il tipo di processo e il numero di processi di quel tipo li chiama formazione. Non è la frase che separa la richiesta dal lavoro lungo. Non le unisco.

La pagina non nomina la mail, né il ridimensionamento di un'immagine, né un numero di secondi. Non glieli assegno io.

I 30 secondi del manuale PHP

La pagina Runtime Configuration ha last-modified 3 novembre 2026 alle 04:08:02 GMT. Il copyright in fondo è 2001-2026, The PHP Documentation Group. Nel testo della direttiva non c'è una data di revisione. Non ne invento una.

max_execution_time è il tempo massimo, in secondi, per cui uno script può girare prima che il parser lo fermi. La pagina dice che serve a evitare che script scritti male tengano occupato il server. Il predefinito è 30. Dalla riga di comando il predefinito è 0. I due predefiniti restano distinti.

Su come si contano quei secondi, la pagina non ha una sola frase. Sui sistemi che non sono Windows, il tempo massimo non è toccato dalle chiamate di sistema, dalle operazioni sugli stream e simili. Rimanda alla funzione set_time_limit per i dettagli. Quella pagina non l'ho aperta. Poi scrive un altro conteggio: se PHP è compilato con i timer di esecuzione, predefinito per le build ZTS da PHP 8.3.0, il limite segue il tempo trascorso, e il sonno e l'attesa di ingresso e uscita contano. Il conteggio predefinito basato su setitimer misura invece il tempo di processore. Tempo di processore e tempo trascorso non sono la stessa misura. Non li unisco. Il 30 resta il predefinito del limite, non la scelta fra i due orologi.

La pagina aggiunge che il server web può avere altre configurazioni di tempo che interrompono PHP. Quella frase non dà un numero. Non gliene assegno uno.

L'altro manuale PHP, tre secondi prima

La pagina di configurazione di PHP-FPM ha last-modified 3 novembre 2026 alle 04:07:59 GMT. Non è le 04:08:02 dell'altra pagina. Non le unisco.

request_terminate_timeout è il tempo per servire una singola richiesta, dopo il quale il processo che la serve viene terminato. La pagina dice di usarlo quando max_execution_time non ferma lo script. Il valore 0 significa spento. Il predefinito è 0. Il processo che serve la richiesta, in questa pagina, non è il processo di lavoro del 2017. Uno serve la richiesta. L'altro, nella pagina del 2017, prende i compiti lunghi in background. Non li chiamo con lo stesso nome.

Una direttiva vicina, request_terminate_timeout_track_finished, ha predefinito no, ed esiste da PHP 7.3.0. Con quel predefinito, il tempo di request_terminate_timeout non scatta dopo fastcgi_finish_request, né mentre girano le funzioni di chiusura interne. La direttiva, se accesa, applica il limite anche in quei casi. Non descrivo come si chiama la funzione. Dico solo quando, secondo questa pagina, il limite non parte.

I 60 secondi di nginx, fra due letture

Il modulo proxy ha last-modified 22 ottobre 2026 alle 11:23:19 GMT. Il modulo FastCGI ha last-modified 22 ottobre 2026 alle 11:23:18 GMT. Un secondo di differenza. Non li unisco in un solo orario.

proxy_read_timeout ha predefinito 60 secondi. Vale nel contesto http, server e location. È il tempo per leggere una risposta dal server proxato. Il tempo è fra due operazioni di lettura successive, non per la trasmissione dell'intera risposta. Se in quel tempo il server proxato non trasmette nulla, la connessione si chiude.

fastcgi_read_timeout ha lo stesso predefinito, 60 secondi, e la stessa frase: fra due letture, non sull'intera risposta. Se il server FastCGI non trasmette nulla in quel tempo, la connessione si chiude. Il 60 di queste due pagine non è il 30 del manuale PHP. Il tempo fra due letture non è il tempo massimo dello script. Non li unisco.

Lo stato 504, senza un numero

La pagina MDN del 504 ha in pagina l'ultima modifica il 22 giugno 2026 alle 01:37:46 UTC. Last-modified della risposta: 3 novembre 2026 alle 00:53:29 GMT. Il 22 giugno e il 3 novembre non coincidono. Non li unisco.

Definisce lo stato come la risposta del server che, facendo da gateway o da proxy, non ha ricevuto in tempo una risposta dal server a monte, e quindi non completa la richiesta. Lo avvicina al 502, con una differenza: nel 504 il proxy o il gateway non ha ricevuto alcuna risposta HTTP dall'origine entro un certo tempo. La pagina non scrive quanti secondi siano quel certo tempo. Non ci metto il 30 e non ci metto il 60.

Che cosa non rimetto

La pagina sull'errore 429 dice che un client ha mandato troppe richieste in un intervallo, e che se c'è un tempo di attesa va rispettato. Non dice dove mettere un lavoro lungo. Non la riscrivo. Errore 429 Too Many Requests: cause e soluzioni.

Non ho riscritto la pagina sulla copia di prova, quella sulla chiave, quella sulla compressione, quella sulla cartella e quella sulle misure. Non ho aperto la pagina su HTTP/3.

Esempio ipotetico

bottega.example è un nome di scuola. Non ho aperto quel nome. Non so se una sua pagina spedisce la mail, ridimensiona un'immagine o chiama un servizio lento mentre il visitatore aspetta.

Non le assegno un processo web, un processo di lavoro, un predefinito di 30 o di 0, un orologio di processore o di tempo trascorso, un 60 fra due letture, né un 504. Non ho misurato un'attesa.

Che cosa questa pagina lascia stare

Non ho misurato un sito. Non ho spostato una mail né un'immagine fuori da una richiesta. La pagina del 2017 non le nomina: le ho usate solo per dire la domanda. I secondi restano quelli delle pagine lette, e non li ho fusi. La copertina di questa pagina è nuova, perché la pagina è nuova.

Fonti lette il 3 novembre 2026. The Twelve-Factor App, Concurrency, Last updated 2017, copyright 2026 in fondo, senza last-modified, https://12factor.net/concurrency. PHP, Runtime Configuration, last-modified 3 novembre 2026 alle 04:08:02 GMT, copyright 2001-2026, https://www.php.net/manual/en/info.configuration.php. PHP-FPM, Configuration, last-modified 3 novembre 2026 alle 04:07:59 GMT, https://www.php.net/manual/en/install.fpm.configuration.php. nginx, ngx_http_proxy_module, last-modified 22 ottobre 2026 alle 11:23:19 GMT, https://nginx.org/en/docs/http/ngx_http_proxy_module.html. nginx, ngx_http_fastcgi_module, last-modified 22 ottobre 2026 alle 11:23:18 GMT, https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html. MDN, 504 Gateway Timeout, ultima modifica in pagina 22 giugno 2026 alle 01:37:46 UTC, last-modified 3 novembre 2026 alle 00:53:29 GMT, https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/504.