Durant una campanya o una hora ocupada, els fitxers estàtics romanen disponibles, però les pàgines de WordPress esperen o retornen errors 502/503. Tots els workers de PHP poden estar ocupats. Augmentar el límit de treballador només pot ajudar si la CPU, la memòria i la base de dades poden suportar més sol·licituds simultànies.
Primer, cerqueu què ocupa cada treballador i per què el trànsit arriba a PHP.
Confirmeu la cua en lloc d’una interrupció general
Correlacioneu el temps d’incidència entre el servidor web, PHP-FPM i mètriques d’hosting. Busqueu avisos de procés assolit, creixement de la cua d’escolta, temps d’espera de la passarel·la i respostes PHP lentes.
Compareu un fitxer estàtic amb un URL dinàmic sense memòria cau. Si el lliurament estàtic és ràpid mentre PHP espera, el grup d’aplicacions és un fort sospitós. Si tots dos fallen, investigueu la capacitat del servidor o de la xarxa de manera més àmplia.
Utilitzeu marques de temps conscients de la zona horària. És possible que els registres de CDN, de servidor i d’anàlisi no comparteixin la mateixa zona horària.
Mesura la concurrència i la durada de la sol·licitud
La demanda dels treballadors es veu aproximadament impulsada per les sol·licituds PHP concurrents multiplicades pel temps que ocupa cadascun d’ells un procés. Deu sol·licituds ràpides poden ser més fàcils que dues trucades lentes d’API externes que cada bloquegen durant segons.
Reviseu els registres lents o les traces d’aplicacions per a la finestra màxima. Agrupa les sol·licituds per ruta: errors de pàgina d’inici, admin-ajax.php, API REST, checkout, cron i bots.
No registreu els cossos de sol·licitud complets ni les dades de pagament. Els camins, la durada i l’estat de resposta solen ser suficients.
Comproveu el percentatge d’èxits de la memòria cau al mateix moment
Una purga de memòria cau de pàgina completa durant un pic de trànsit pot enviar tots els visitants a PHP. També ho pot fer una galeta o un paràmetre de consulta que omet la memòria cau.
Inspeccioneu les mètriques d’error i errors de la memòria cau i els esdeveniments d’invalidació. Confirmeu si una publicació de contingut, una actualització d’estoc o un desplegament ha esborrat memòria cau amplies immediatament abans de formar-se la cua.
Protegiu les rutes de WooCommerce dinàmiques, però milloreu la capacitat de memòria cau per a pàgines realment públiques. No emmagatzemeu mai a la memòria cau HTML de pagament per reduir l’ús dels treballadors.
Busqueu trucades externes lentes
SMTP, comprovacions de llicències, fonts remotes, serveis de divises i API de seguiment poden bloquejar els workers de PHP mentre esperen un altre servidor. Els rastres d’aplicacions o els registres lents de PHP poden revelar funcions de xarxa a la pila.
Establiu temps d’espera raonables i traslladeu el treball no essencial a un treball de fons on el connector ho admeti. No suprimiu una resposta de pagament requerida o una verificació de webhook.
Emmagatzema a la memòria cau dades remotes estables amb un comportament explícit de caducitat i error.
Inspeccioneu les tasques cron i asíncrones
WordPress cron, Action Scheduler i treballs de còpia de seguretat poden llançar moltes sol·licituds PHP alhora. Relaciona els registres de treball amb la finestra de saturació.
Executeu treballs recurrents pesats fora de les sol·licituds de pàgines generades pels visitants on l’hosting ho permeti i eviteu els corredors duplicats. Esglaoneu les còpies de seguretat, la regeneració d’imatges i les alimentacions lluny dels pics coneguts.
No suprimiu les accions pendents de WooCommerce indistintament. Poden representar correus electrònics, pagaments, subscripcions o actualitzacions d’existències.
Avalueu els límits dels treballadors amb memòria i CPU
Cada procés PHP consumeix memòria i els processos concurrents competeixen per connexions de CPU i bases de dades. Reviseu la memòria màxima real per treballador i l’espai total del servidor.
Aixecar pm.max_children sense capacitat pot crear intercanvis i fer que cada sol·licitud sigui més lenta. A l’hosting gestionat, els recomptes de treballadors es poden aplicar segons el pla; les mètriques del proveïdor poden mostrar les visites límit.
Reduïu la durada per sol·licitud i el trànsit PHP innecessari abans de comprar capacitat i, a continuació, dimensioneu el grup a partir de la demanda mesurada.
Prepara un comportament màxim elegant
Escalfeu les pàgines públiques crítiques després de purgues controlades, limiteu la velocitat dels endpoints abusius i assegureu-vos que el CDN pugui absorbir trànsit estàtic. Protegiu l’inici de sessió i la cerca cara sense bloquejar clients legítims.
Utilitzeu un missatge de manteniment o de cua només quan sigui necessari i eviteu els bucles de reintent que augmentin la càrrega. Superviseu la taxa d’errors, la cua i els resultats de la compra satisfactoris durant el proper pic.
Quan es justifiqui una intervenció urgent
Sol·liciteu una reparació urgent del rendiment quan les comandes fallin, els registres PHP-FPM mostren l’esgotament repetit del grup o la ruta arrel no està clara. Compartiu primer temps d’incidència, registres desinfectats i URL afectats.
Una reparació responsable hauria de reduir la feina dels treballadors, preservar el comportament dinàmic del comerç electrònic i només aleshores recomanar capacitat addicional basada en l’evidència.