A volte si verificano errori Gateway, di solito 502 Bad Gateway o 504 Gateway Timeout.
Questi sono errori restituiti dal server web (Apache, Nginx, etc.) quando invia una richiesta a PHP, ma PHP restituisce un errore dicendo che non può elaborare la richiesta. Di solito questi non sono errori che si verificano nella tua applicazione, ma sono invece (di solito) errori che si verificano prima che l’applicazione elabori una richiesta.
Cos’è un Gateway
Un Gateway è un elemento che si trova tra il server web (di solito Nginx) e la tua applicazione. In questa guida usiamo come esempio PHP-FPM. Nginx utilizzerà il protocollo fastcgi per convertire una richiesta web in qualcosa che PHP-FPM può capire. PHP-FPM quindi esegue la tua applicazione, configurando PHP con le informazioni di cui ha bisogno (impostando le superglobali $_GET, $_POST, $_SESSION, $_SERVER, ecc.).
Se PHP-FPM va in errore, Nginx ci restituisce un errore di Gateway.
502 Bad Gateway
Bad Gateway viene restituito quando PHP-FPM restituisce un errore. Di solito si tratta di uno di questi:
- PHP-FPM non è in esecuzione (forse a causa di troppi errori)
- PHP-FPM ha raggiunto il limite max_children e non può elaborare ulteriori richieste
- Qualche tipo di errore PHP, come un segfault
504 Gateway Timeout
Gli errori di timeout del Gateway si verificano di solito quando la tua app gestisce troppo traffico. Questo può corrispondere a errori di max_children di PHP-FPM (troppe richieste rispetto a quanto sia configurato per gestire), ma si verifica principalmente quando il tuo database è sovraccarico e non può gestire connessioni aggiuntive per eseguire query. In pratica il DB ci mette troppo tempo per restituire le query.
Ciò può verificarsi anche se qualsiasi connessione di rete che la tua applicazione effettua non restituisce risposte in tempo, ma il database è il collo di bottiglia più comune.
Debugging degli errori
Per un efficace debug degli errori di Gateway devi controllare i log. Parti dall’inizio dello stack delle richieste di rete e scendi. Ciò significa che l’ordine dei log che devi controllare è:
- Nginx
- PHP-FPM
- Utilizzo delle risorse del server
- Log dell’applicazione
I log di Nginx di solito hanno dati meno utili, anche se potrebbero darti un’idea dei problemi di PHP-FPM non in esecuzione (se non riesce a trovare il file socket di PHP-FPM come ad esempio /var/run/php-fpm.sock).
I log di FPM sono di solito i più utili, poiché PHP-FPM è il gateway che restituisce l’errore! Spesso vedrai un errore relativo al raggiungimento (o alla vicinanza) del limite max_children. Meno frequentemente potresti vedere un errore di segfault (se lo vedi, probabilmente hai una ricorsione nel tuo codice da qualche parte).
L’utilizzo delle risorse del server è ciò che controllerai successivamente. Usa htop o simili per controllare l’utilizzo della CPU/RAM e quali processi li stanno utilizzando. Verifica anche se il disco è pieno, con l’istruzione:
df -hPotresti anche esaurire gli inode! Gli inode sono “nodi di indice”, elementi utilizzati per tracciare l’utilizzo dei file nei sistemi Linux. Poiché tutto è un file (compreso il modo in cui Linux gestisce le connessioni di rete aperte!), esaurire gli inode può essere un problema. Per visualizzare l’utilizzo degli inode per unità disco puoi eseguire:
df -iInfine, controlla i log dell’applicazione. Questi potrebbero mostrare errori legati a timeout o errori del database, anche se a volte il problema non è collegato al codice dell’applicazione. L’utilità di questo check può variare a seconda del tipo di errore.
Se ti rendi conto che qualche query è troppo pesante, cerca di ottimizzarla. Se stai lavorando su un framework con ORM (ad esempio Laravel), come primo passo recupera la raw query realmente eseguita dal builder SQL.
Tradotto liberamente da qui.