Cosa causa l'avviso "max_user_connections" nel frontend di WordPress?

Non è relativo a WordPress, quindi non sono sicuro di avere il diritto di rispondere qui, ma puoi comunque aumentare max_user_connections nel file di configurazione my.cnf di MySQL visto che stai solo testando.

Ci sono diverse cause per l'esaurimento delle connessioni, le più comuni riguardano situazioni in cui il server Web/App crea un numero insolitamente elevato di connessioni a causa di una configurazione errata, di uno script che perde connessioni o ne crea troppe per errore.

La soluzione: alcune persone aumentano max_connections a un numero molto alto così che MySQL non esaurisca mai le connessioni.

Tuttavia, questo può causare problemi di utilizzo delle risorse, consumando memoria e facendo sì che il server MySQL venga terminato dal processo OOM killer o che abbia prestazioni molto scarse a causa dell'elevata contesa.

Per prima cosa, vuoi abilitare gli errori per $wpdb, l'astrazione del database di WordPress:

$GLOBALS['wpdb']->show_errors;

Altrimenti nessuna delle tue connessioni al database morirà davvero e interromperà con un'istanza di \WP_Error. Il codice di errore predefinito è un 500.

Il seguente errore proviene da \wpdb::db_connect():

Errore durante la connessione al database

Ci sono due casi in cui db_connect() entra in gioco:

1. Connettersi al database
2. Verificare se esiste una connessione al database

Solo il primo è autorizzato a interrompersi. Se la connessione morisse mentre viene eseguito solo il controllo, non interromperà e non genererà questo errore. Ora la connessione viene stabilita da \wpdb_driver::connect(), che verifica se la connessione è abilitata e disponibile. Questo ti dice che il tuo problema effettivo è proprio la connessione stessa. Puoi verificarlo (non è uno scherzo) nel seguente file:

# interface-wp-db-driver.php
<?php
abstract class wpdb_driver {

È meglio non pensare se ci sia qualche correlazione tra la qualità complessiva del codice core di WP e la profonda comprensione delle interfacce e delle classi astratte qui.

Poco prima che la connessione al database venga dichiarata "fallita" e l'errore venga visualizzato, c'è una bella riga:

require_once WP_CONTENT_DIR . '/db-error.php';

Questo significa che viene caricato un Drop In prima che tutto die. Puoi usarlo e avviare un meccanismo di debug lì. Hai a disposizione tutto il core di WP lì dentro. Puoi iniziare a inviarti email, registrare quegli errori in qualche stack ELK/Kibana, Spark o qualsiasi altro, qualche SaaS o persino su Slack (o semplicemente su un file di testo). Registra i tuoi errori lì, registra cosa sta succedendo, esamina le route, le richieste, i dettagli della connessione al database, qualsiasi cosa pensi possa aiutarti.

I server web sono multitasking... Assumendo che il tuo tema non tenti di accedere al database direttamente (non tramite la classe WPDB), ogni connessione utente dovrebbe corrispondere al tempo di elaborazione di una richiesta gestita da WordPress.

Assumendo questo, probabilmente hai un rallentamento nell'elaborazione di ogni richiesta, combinato con diverse richieste gestite "contemporaneamente" - cosa che può accadere se il tuo tema carica dinamicamente contenuti tramite AJAX.

(questo è fondamentalmente ciò che ti ha detto il tuo hosting, e ha senso)