PHP

Що забуває воркер PHP — і дванадцять наслідків

Сервіс на Java, Node.js чи Go стартує один раз і далі тижнями обслуговує запити з того самого процесу. Усе, що він поклав у пам’ять, там і лишається: кеш, пул з’єднань, лічильник, таймер. Воркер PHP робить навпаки. Він будує застосунок з нуля для кожного запиту і викидає все це, щойно відповідь надіслано. Майже все, що дивує розробника, який прийшов з іншої мови, випливає з цієї однієї різниці. Ось дванадцять наслідків — для кожного звичка, яку він ламає, і те, що PHP робить натомість. Наступні розділи посилаються на рядки за номерами.

Один запит, один чистий процес — і пул зі стелею

PHP майже ніколи не говорить із мережею сам. Вебсервер — nginx, Apache чи Caddy — приймає з’єднання й передає запит протоколом FastCGI до PHP-FPM, менеджера процесів FastCGI. FPM тримає пул робочих процесів. Вільний воркер бере запит, завантажує фреймворк, виконує ваш код, пише відповідь — і викидає кожен створений об’єкт, змінну й з’єднання. Наступний запит отримує воркер у тому самому порожньому стані. Це модель shared-nothing: запити навмисно не ділять у пам’яті нічого.

Плюс у тому, що цілий клас помилок просто не може існувати. Витік об’єкта, зіпсована глобальна змінна, з’єднання в поламаному стані — усе це викидається за мілісекунди, тож запит здатен отруїти лише сам себе. Фатальна помилка забирає один запит, а не сервер. Масштабування так само прямолінійне: воркери нічого не ділять, тож більше потужності — це більше воркерів, а більше воркерів на більшій кількості серверів не потребують жодної координації, крім бази даних.

Пул — це стеля

Рядок 12 — той, що спричиняє аварії. Воркер обробляє один запит за раз, тож розмір пулу — це кількість запитів, які PHP може обслуговувати одночасно, а стандартний конфіг FPM задає pm.max_children = 5. Свіже встановлення обробляє п’ять одночасних запитів; шостий чекає в черзі. Правильне число береться з пам’яті, а не з процесора: виміряйте, скільки займає один воркер під реальним трафіком, поділіть на це пам’ять, яку можна віддати PHP, і лишіть місце для решти на машині. За 4 ГБ для PHP і 64 МБ на воркер це близько шістдесяти воркерів.

Тоді в пулу є стеля пропускної здатності, і це проста арифметика: кількість воркерів, поділена на час одного запиту. Шістдесят воркерів по 100 мс на запит обслуговують 600 запитів за секунду. Тепер нехай платіжний провайдер сповільниться до 2 секунд. Кожен запит, що його викликає, тримає свій воркер 2 секунди, ті самі шістдесят воркерів обслуговують 30 запитів за секунду, а все понад це стає в чергу. Схема показує це на пулі з восьми. Графік процесора весь цей час показує майже вільний сервер, бо очікування не коштує процесорного часу, — тому цю аварію так часто хибно читають як «замало серверів».

Мова, яку пам’ятають, і мова, яка існує

Більшість думок про PHP склалася на PHP 5: жодних типів, порівняння без логіки й проблема зі швидкістю, настільки серйозна, що Facebook написав власний компілятор. PHP 7.0, у грудні 2015 року, переписав рушій і став до двох разів швидшим за 5.6, а кожен реліз відтоді додавав щось до системи типів. Тепер реліз виходить щолистопада, отримує два роки виправлень помилок і ще два — виправлень безпеки, а потім — нічого. Таблиця перелічує, що кожен із них додав такого, що ви справді зустрінете в коді, і як довго він отримує патчі.

Суворі типи: вирішує файл, що викликає

Оголошення типів у PHP мають два режими. За замовчуванням вони приводять значення: передайте рядок "5" у параметр int, і PHP тихо перетворить його на 5. З declare(strict_types=1) угорі файлу вони перевіряють: той самий виклик кидає TypeError. Частина, у якій помиляються майже всі, — котрий файл вирішує. Словами посібника, суворі типи «застосовуються до викликів функцій, зроблених у файлі з увімкненою суворою типізацією, а не до функцій, оголошених у цьому файлі». Функція, написана в суворому файлі, однаково приводить значення, коли її викликають із файлу без цього рядка.

Практичне правило випливає саме: ставте цей рядок у кожен файл, разом із тестами й шаблонами, і хай інструмент перевірки стилю за цим стежить. Бібліотека не може зробити власні функції суворими для тих, хто їх викликає. Її єдиний захист — статичний аналіз на боці того, хто викликає. PHPStan і Psalm читають оголошення й знаходять null, що доходить до виклику методу, раніше за користувача. Обидва працюють рівнями — у PHPStan їх одинадцять, від 0 до 10, з релізу 2.0 у листопаді 2024 року, — тож наявна кодова база може підніматися на рівень за раз, а не одним неможливим ривком.

Порівняння, які PHP 8 виправив, і ті, що лишилися

Репутацію «дивних порівнянь» заробив нестрогий оператор ==, що перетворює обидва боки, перш ніж порівняти. PHP 8 змінив одне правило: число, яке порівнюють із рядком, що не схожий на число, тепер порівнюється як рядок. Це прибрало найгірші випадки. Решта лишилася, і саме через неї ===, що порівнює тип і значення без перетворень, — типовий вибір у сучасному коді.

Про JITJITJust-In-Time compilation — компіляція під час роботиКомпіляція коду тоді, коли програма вже працює: середовище спершу виконує його як є, дивиться, які ділянки гарячі, і на ходу перетворює саме їх на машинний код. Тому перші секунди після старту повільніші за наступні хвилини.Усі терміни-компілятор, доданий у 8.0, варто говорити чесно. Він помітно пришвидшує довгі числові обчислення й майже не впливає на типові вебзапити, бо вебзапит проводить час в очікуванні бази даних і мережі, а не в арифметиці. Якщо PHP-сторінка повільна, відповідь — у лозі запитів і в рядку 6, а не в JIT.

Laravel, Symfony і стандарти під ними

Майже ніхто не починає PHP-застосунок із порожньої теки. Composer, менеджер залежностей, ставить пакети з Packagist і записує точні обрані версії в composer.lock; комітьте цей файл і на сервері запускайте composer install, ніколи composer update. Composer також генерує автозавантажувач, тож ви не напишете жодного require для власних класів. Автозавантажувач працює завдяки стандарту: PHP-FIG, група авторів фреймворків і бібліотек, публікує PSR — PHP Standard Recommendations, — що дають коду з різних проєктів стикуватися між собою.

Над цим шаром поле тримають два фреймворки, і вибір між ними — це вибір, скільки фреймворк вирішує за вас.

Чесне резюме: типовій продуктовій команді Laravel швидше дає робочу фічу, а ризик — архітектурний дрейф. Для системи, яку банк експлуатуватиме ще дванадцять років, явність Symfony варта церемонії. Обидва підтримуються й достатньо швидкі. Різниця між доброю і поганою кодовою базою в кожному — це дисципліна щодо того, де живе бізнес-логіка, а не фреймворк.

База даних і шість викликів, які варто пошукати перед кожним релізом

Репутація PHP щодо SQL-ін’єкцій виросла зі справжньої епохи запитів, склеєних із рядків, а виправлення є стандартом уже понад десятиліття: підготовлені вирази. Підготовлений вираз надсилає форму запиту й значення окремо, тож значення ніколи не прочитають як SQL. Кожен ORMORMObject-Relational Mapping — обʼєкти замість SQLБібліотека, що підставляє обʼєкти мови там, де в базі лежать рядки таблиці, — тож SQL ви майже не пишете. Зручність коштує контролю: згенерований запит буває значно важчим за той, який ви написали б самі, і зʼясовується це вже під навантаженням.Докладніше в статті →Усі терміни і будівник запитів в екосистемі використовує їх під капотом. Єдиний шлях назад до вразливості — вручну вставити змінну в SQL.

Ще дві звички відрізняють кодову базу, що переживає зростання, від тієї, що ні. Тримайте транзакції короткими: транзакція, відкрита на час HTTP-виклику до платіжного провайдера, блокує свої рядки рівно стільки, скільки той провайдер гальмує, і ще й тримає воркер (рядок 12). І тримайте міграції в системі контролю версій поруч із кодом, якому вони потрібні, щоб деплой і зміна схеми рухалися разом.

Ін’єкція — не єдині двері. Більшість серйозних вразливостей PHP походить від короткого списку викликів, безпечних із вашими даними й небезпечних із чужими. Кожен легко знайти текстовим пошуком, тож цей список — дешевий крок рев’ю перед кожним релізом:

Довгоживучий PHP: що worker mode повертає і що забирає

Тепер є й другий спосіб запускати PHP. Сервери застосунків завантажують фреймворк один раз і далі обслуговують багато запитів із того самого процесу. FrankenPHP, побудований на вебсервері Caddy й офіційно підтримуваний PHP Foundation з травня 2025 року, називає це worker mode. RoadRunner робить це з процесу на Go; Swoole й OpenSwoole — як розширення PHP із корутинами; Laravel Octane обгортає всі три, а Symfony працює на них через свій компонент Runtime.

Повертає це рядки 1, 5 і 9. Ініціалізація оплачується один раз, тож запит, що більшість часу завантажував фреймворк, стає в кілька разів швидшим. Кеш усередині процесу й постійне з’єднання знову щось означають. А забирає це страховку моделі shared-nothing. Пам’ять більше не стирається між запитами, тож усе, що запит лишив на довгоживучому об’єкті, видно наступному — а наступний належить іншому користувачеві.

Код, написаний під FPM, ніколи на це не тестувався, бо під FPM цього не могло статися. Перед переходом перевірте п’ять речей:

П’ять кейсів і те, чого в кожному бракувало

Кожен кейс нижче задокументовано у власних оголошеннях, баг-трекері й поштовій розсилці PHP або в опублікованому дослідженні, що його знайшло. Разом вони покривають рушій, стик із вебсервером, репозиторій вихідного коду, вікно підтримки й шар фреймворку.

Перший кейс — причина, з якої розділ про мову починається із заяви про швидкість. У лютому 2010 року Facebook оголосив HipHop, що перекладав PHP на C++, бо стандартний рушій не встигав за його трафіком, а згодом замінив його на HHVM — віртуальну машину з JIT. Кілька років найшвидший спосіб запускати PHP був не від самого PHP. Відповідь прийшла зсередини проєкту: PHP 7.0, випущений 3 грудня 2015 року, перебудував ключові структури даних рушія й став, словами оголошення про реліз, «до двох разів швидшим за PHP 5.6». У вересні 2018 року команда HHVM оголосила, що припиняє підтримку PHP, і HHVM 4.0, у лютому 2019 року, виконує лише Hack — власну мову Facebook. Команди, що перейшли на HHVM заради швидкості, перейшли назад. Форк, швидший за оригінал, — це ставка на дорожню карту однієї компанії.

Третій кейс — про власний код мови. 28 березня 2021 року в php-src на власному git-сервері PHP з’явилися два коміти, підписані іменами Расмуса Лердорфа, що створив PHP, і Нікіти Попова, одного з найактивніших розробників. Їх позначили як виправлення друкарських помилок. Вони додавали код, що виконував будь-який PHP, надісланий у заголовку User-Agentt — зверніть увагу на друге t, — який починався зі слова «zerodium». Розробники, що читали потік комітів, помітили перший за кілька годин і відкотили; другий повернув той самий код і теж був відкочений. Наступного дня проєкт зробив основним свій репозиторій на GitHub, з обов’язковою двофакторною автентифікацією для права запису. Пізніший висновок: git-сервер, імовірно, не зламували взагалі — найпевніше, витекла база користувачів за ним, тож зловмисник пушив зі справжніми обліковими даними. Рев’ю спрацювало. Ідентичність — ні.

П’ятий кейс поєднує перший рядок таблиці пошуку із секретом. Laravel шифрує cookiecookieдані, які браузер надсилає назадНевеликий фрагмент даних, який сайт просить браузер зберегти й надсилати назад із кожним запитом до цього сайту, — так сервер пам’ятає, що ви увійшли. Оскільки браузер додає його автоматично, навіть до запиту, який спровокував інший сайт, cookie сесії потребує правильних прапорців і перевірки проти підробки запитів на сервері.Усі терміни та інші значення ключем застосунку APP_KEY, а його функція decrypt() за замовчуванням десеріалізує те, що розшифрувала. Тож хто має ключ, може зашифрувати об’єкт на свій вибір, передати його застосунку — і той його десеріалізує: віддалене виконання коду. Для старих версій Laravel це була CVECVECommon Vulnerabilities and Exposures — публічний номер відомої вразливостіПублічний ідентифікатор відомої вади безпеки, як-от CVE-2021-44228 для Log4Shell, щоб постачальники, сканери й бюлетені мали на увазі той самий баг. Номер каже, що вада існує; наскільки вона небезпечна саме для вас, залежить від того, чи працює у вас уражена версія і чи відкрита назовні вражена частина.Усі терміни-2018-15133. У липні 2025 року GitGuardian і Synacktiv опублікували, що це означає в масштабі: вони витягли понад 260 000 значень APP_KEY з публічних репозиторіїв GitHub, закомічених між 2018 роком і травнем 2025-го, і знайшли понад 600 живих застосунків, які можна було ними захопити. Ключ потрапляв у репозиторій разом із файлом .env чи вставленим у конфіг і ніколи не змінювався. Усі заходи були звичайними — сканер секретів на кожен пуш, ротація, коли ключ витік, — а урок дизайну старий: ніколи не дозволяйте одному секрету бути єдиним, що стоїть між інтернетом і unserialize().

Де він вироджується

Модель PHP поблажлива, і це водночас її сила і спосіб, у який вона відмовляє. Витік, погана глобальна змінна чи повільний цикл коштують одного запиту й забуваються, тож кодова база може нести чимало безладу, перш ніж щось помітно зламається. Коли ж ламається, це майже завжди один із дванадцяти рядків, який проігнорували, або один із шести викликів, якому довірили чужі дані:

• Повільна робота всередині запиту — листи, PDF, сторонні виклики — замість черги (рядок 6).
• Пул, залишений на стандартних п’яти воркерах або розрахований від процесора замість пам’яті (рядок 12).
• Жодного тайм-ауту реального часу на вихідних викликах, тож одна повільна залежність тримає всі воркери.
• Сесії чи завантаження на локальному диску: працює на одному сервері й тихо ламається на двох (рядки 2 і 3).
• Запити N+1N+1зайвий запит на кожен рядокКласична пастка ORM: один запит дістає список, а потім цикл по ньому тихо робить ще по запиту на кожен елемент — сто рядків перетворюються на сто одне звернення до бази. Лікується тим, щоб попросити повʼязані дані одразу, а не рядок за рядком.Докладніше в статті →Усі терміни за зручним зв’язком, невидимі, доки в таблиці не з’являться справжні дані.
• Файли без strict_types: оголошення типів приводять значення замість перевірки й дають хибну впевненість.
• Бізнес-логіка всередині контролерів і моделей — доки правило можна перевірити лише через HTTP-запит.
• unserialize() на будь-чому, що пройшло мережею, або ключ фреймворку, закомічений у репозиторій.
• Worker mode, увімкнений заради швидкості без перевірки, що довгоживучі об’єкти тепер тримають між користувачами.
• Версія за межею останньої колонки таблиці, де наступний бюлетень безпеки не матиме патча.

Чесна межа — сама модель. Запит, що має лишатися відкритим, — чат, живий дашборд, стрим, — увесь час бореться з задумом «один запит — один воркер», і правильна відповідь зазвичай — другий, маленький сервіс на іншому середовищі поруч із PHP-застосунком, а не PHP-застосунок, вигнутий під цю форму. Те саме з важкими обчисленнями й конвеєрами даних: середовище здатне їх виконати, але бібліотеки, інструменти й люди — деінде. Worker mode звужує розрив, не закриваючи його, і купує свою швидкість саме тією страховкою, що робила PHP простим для міркувань.

Практична перевірка займає п’ять хвилин. Запустіть php -v на продакшн-сервері й знайдіть рядок у таблиці версій. Запустіть composer audit, що перелічує встановлені пакети з відомими бюлетенями безпеки. Відкрийте сторінку статусу FPM (pm.status_path) під реальним трафіком і порівняйте «active processes» з pm.max_children: якщо в пік вони рівні, рядок 12 уже ваше вузьке місце.

Коли це застосовувати

Пов’язані сторінки

• РозробкаNode.jsNode.js — серверне середовище для JavaScript, що виконує весь ваш код в одному потоці й передає кожне очікування операційній системі або невеликому пулу потоків. Саме через цей задум один процес тримає десять тисяч простійних з’єднань — і саме через нього одна повільна функція затримує всі запити одночасно. Сторінка починається з сімнадцяти дій Node-сервера й того, який потік платить за кожну; далі — цикл подій і пул, релізи й підтримка (з Node 27 — один мажорний реліз на рік), що тепер вбудовано, масштабування й коректна зупинка, п’ять задокументованих кейсів і те, де все це вироджується.
• РозробкаМонолітМоноліт — це застосунок, який збирають, тестують і деплоять як одне ціле, незалежно від його розміру й того, як організовано код усередині. Більшість скарг на моноліти насправді стосується відсутніх меж усередині — це інша проблема з дешевшим лікуванням, — а моноліт зі справжніми межами модулів є правильним вибором за замовчуванням для більшості систем. Сторінка починається з шістнадцяти поширених скарг і того, де насправді живе кожна; далі — дві осі, які плутає кожна суперечка про архітектуру, чому один артефакт — вибір за замовчуванням і який найкращий аргумент проти, як провести й утримати межі модулів, як експлуатувати великий моноліт, де він справді вичерпується, п’ять задокументованих кейсів і де все це вироджується.
• РозробкаPythonPython — мова загального призначення, чий стандартний інтерпретатор виконує код Python в одному потоці за раз, а важкі обчислення лишає скомпільованим бібліотекам. Саме через це блокування, GIL, чотири потоки рідко бувають учетверо швидшими, вебсервери на Python працюють кількома процесами, а повільний сервіс потребує діагнозу до лікування: він чекає чи обчислює? Сторінка починається з дванадцяти навантажень і інструмента, що справді пришвидшує кожне; далі — GIL і нова збірка без нього, asyncio, версії й щорічний реліз, типи й пакування, вебсервери та їхня пам’ять, п’ять задокументованих кейсів і те, де все це вироджується.