Acum două săptămâni, pe un worker PHP 8.2 CLI care procesa cozi de ~120k mesaje/zi, RSS-ul creștea de la 60 MB la 900 MB în șase ore, apoi OOM killer. Nu era PHP-FPM, deci nu se aplicau sfaturile obiș
Un serviciu mic, PHP 8.2.11, Alpine în container, opcache activat, `opcache.validate_timestamps=1`. La deploy, un fișier `Bootstrap.php` dintr-un pachet intern era inclus cu `require_once` din două lo
Rulez un serviciu mic pe PHP 8.2, Alpine, container de 512 MB, care primește webhook-uri JSON de la un partener. Volumele nu sunt mari: 3–4 req/s, dar payload-urile variază între 200 KB și 2,3 MB. La
Pe un PHP 8.1 cu PHP-FPM (procese statice, 24 de copii) și un Apache în față, un endpoint de dashboard răspundea în 1,4–1,8 s la TTFB, deși interogările SQL luau sub 40 ms fiecare. Trafic de ~90 req/s
Un client urca fișiere prin formular pe un server cu PHP 8.2, nginx 1.24 și PHP-FPM pe socket Unix. Fișierele mici mergeau, cele peste 8 MB dădeau 502 după exact 60 de secunde. Nu era load, era un sin
Acum două săptămâni, pe un VPS cu 4 GB RAM și PHP 8.2, un endpoint de raportare genera fișiere CSV de aproximativ 80 MB. Totul rula pe PHP-FPM cu `pm = dynamic` și `pm.max_children = 120`. La 30–40 de
Rulez PHP 8.2.13 cu FPM pe o mașină cu 8 vCPU și 16 GB RAM, Nginx în față. La vreo 400 req/s, cu un endpoint care face două interogări MySQL și un apel către un serviciu intern, apare un comportament
Rulez un API pe PHP 8.2.14, Nginx 1.24, PHP-FPM cu pool-ul `www` pe 4 procese copii, pe un VPS cu 8 GB RAM și 4 vCPU. Sub 200 req/s constante, cam la 20 de minute, `pm.max_children` se umple, coada di
Am avut un incident acum câteva luni pe un MySQL 8.0.32, 16 vCPU, 64 GB RAM, InnoDB, cu vreo 400 GB de date și un vârf de 2.500 conexiuni active. Simptomul: la fiecare ~40 de minute, `SHOW PROCESSLIST
