Assicurati di leggere questa risposta di seguito , che descrive i modi per mitigare i problemi descritti qui.
Gli stessi svantaggi esistono usando PDO come con qualsiasi altra interfaccia di database PHP che esegue connessioni persistenti: se lo script termina inaspettatamente nel mezzo delle operazioni del database, la richiesta successiva che ottiene la connessione rimanente riprenderà da dove lo script morto era stato interrotto. La connessione viene mantenuta aperta a livello del gestore processi (Apache per mod_php, l'attuale processo FastCGI se si utilizza FastCGI, ecc.), Non a livello di PHP, e PHP non dice al processo padre di interrompere la connessione quando lo script termina in modo anomalo.
Se lo script morto ha bloccato le tabelle, quelle tabelle rimarranno bloccate fino a quando la connessione non si interrompe o lo script successivo che ottiene la connessione sblocca le tabelle stesse.
Se lo script dead si trovava nel mezzo di una transazione, ciò può bloccare una moltitudine di tabelle fino a quando non scatta il timer deadlock, e anche in questo caso, il timer deadlock può uccidere la richiesta più recente invece della richiesta precedente che causa il problema.
Se lo script morto si trovava nel mezzo di una transazione, anche lo script successivo che ottiene quella connessione ottiene lo stato della transazione. È molto possibile (a seconda del progetto dell'applicazione) che lo script successivo in realtà non provi mai a eseguire il commit della transazione esistente o commetterà quando non dovrebbe avere o eseguirà il rollback quando non dovrebbe.
Questa è solo la punta dell'iceberg. Può essere mitigato in una certa misura provando sempre a ripulire dopo una connessione sporca su ogni singola richiesta di script, ma ciò può essere una seccatura a seconda del database. A meno che non avete individuato la creazione di connessioni al database come l'unica cosa che è un collo di bottiglia nello script (questo significa che hai fatto il codice profiling utilizzando xdebug e / o xhprof ), si dovrebbe non prendere in considerazione le connessioni persistenti come una soluzione per qualsiasi cosa.
Inoltre, i database più moderni (incluso PostgreSQL) hanno i loro modi preferiti di eseguire il pool di connessioni che non hanno gli svantaggi immediati delle semplici connessioni persistenti basate su PHP.
Per chiarire un punto, usiamo connessioni persistenti sul mio posto di lavoro, ma non per scelta. Stavamo riscontrando uno strano comportamento di connessione, in cui la connessione iniziale dal nostro server delle applicazioni al nostro server di database impiegava esattamente tre secondi, quando avrebbe dovuto impiegare una frazione di una frazione di secondo. Pensiamo che sia un bug del kernel. Abbiamo rinunciato a cercare di risolverlo perché si è verificato in modo casuale e non è stato possibile riprodurlo su richiesta e il nostro IT esternalizzato non ha avuto la capacità concreta di rintracciarlo.
Indipendentemente da ciò, quando le persone nel magazzino stanno elaborando alcune centinaia di parti in arrivo, e ogni parte impiega tre secondi e mezzo invece di mezzo secondo, abbiamo dovuto agire prima che ci rapissero tutti e ci facessero aiutare. Quindi, abbiamo lanciato alcuni bit nella nostra mostruosità ERP / CRM / CMS cresciuta in casa e abbiamo sperimentato di persona tutti gli orrori delle connessioni persistenti. Ci sono volute settimane per rintracciare tutti i piccoli problemi sottili e i comportamenti bizzarri che sembravano essere casuali. Si è scoperto che quegli errori fatali una volta alla settimana che i nostri utenti hanno diligentemente spremuto dalla nostra app stavano lasciando tavoli bloccati, transazioni abbandonate e altri sfortunati stati traballanti.
Questo sob-story ha un punto: ha rotto cose che non ci saremmo mai aspettati di rompere, tutto in nome della performance. Il compromesso non è valsa la pena, e stiamo aspettando con impazienza il giorno in cui potremo tornare alle normali connessioni senza una rivolta dei nostri utenti.