Прискорення PHP програм. Оптимізація PHP – головна ознака професійного коду eAccelerator: прискорення повторного завантаження PHP-коду

Увімкнення динамічного стиснення готових HTML - сторінок (

) може стиснути їх у середньому на 20-60%, збільшуючи швидкість завантаження та знижуючи кількість «висять» процесів. У вас обмеження щодо трафіку на хостингу? Тоді динамічний стиск сторінок принесе подвійну вигоду.

Звичайно, слід враховувати, що буферизація дещо підвищує споживання пам'яті, а стиснення навантаження на процесор. Але ці жертви найчастіше з лишком окупаються приростом швидкості. Причому як швидкістю створення, а й швидкістю завантаження сторінки.

На завершення, фронтенд http-сервер може вивести продуктивність ваших PHP скриптів на новий рівень. Справа в тому, що навіть з кешуванням, процеси, пов'язані із запитом користувача, «висітимуть» до того, поки користувач не прийме всі дані (або поки не вийде ліміт відведеного на це часу). Суть фронтенд сервера в тому, щоб відразу ж приймати дані, дозволяючи відразу вивантажувати процеси, що відпрацювали. Він є якоюсь сполучною ланкою між користувачем і досить «важким» сервером бекенд — де виконуються ваші PHP скрипти. Але завдяки своїй «легкості», фронтенд сервер суттєво знижує споживані ресурси. Знову ж таки, це дуже велика тема і ми розглядатимемо її більш детально, у найближчому майбутньому.

6) Тотальний іклуд

Припустимо, ви створили свій «движок» на PHP, дотримувалися всіх попередніх порад. У ньому практично неминуче буде безліч різних інклудів: файлів конфігурації, функцій, мов і т.д. Суть зводиться до того, що навіть звичайний іклуд того ж файлу з функціями вимагатиме чимало часу і пам'яті, навіть якщо крім функцій в інклуді немає виконуваного коду, і не одна з функцій не викликається.

Але ж функції бувають найрізноманітніші та найспецифічніші. Отже, поміщати весь список функцій в один файл, і щоразу підключати його — не найкращий вихід. Наприклад, на сайті є реєстрація користувачів: для цього у вас може бути низка спеціальних функцій, які використовуються лише при реєстрації. То навіщо виносити їх у загальний інклуд функцій, який підключатиметься при кожному зверненні до сторінок сайту?

Не нехтуйте оптимізацією інклудів. Виносите те, що застосовується не повсюдно окремі, спеціалізовані інклуди. Ще один приклад для закріплення. Мій улюблений движок новинного сайту. Функції додавання новин, коментарів, їх контролю та пре-парсингу займає близько 1/3 коду загальної кількості функцій. Але як часто вони потрібні? В 1 із 100 запитах? Або в 1 із 200? Або ще рідше? То навіщо ж їх щоразу вантажити? Це справді може суттєво знизити продуктивність ваших рішень.

7) Зайва функціолізація та ООП-тимізм

Функції необхідно застосовувати лише тоді, коли це справді має сенс. Давайте пригадаємо базову мету функцій. Це не що інше, як винос

частин коду окрему, загальну часть. У принципі, виносити код в «окрему частину» має сенс і тоді, коли він виконується за деякою відносно малоймовірною подією. Наприклад, прикріплення фото до поста на форумі. Винесення обробника завантаження та обробки картинки в «окрему частину» позитивно позначиться на продуктивності, навіть якщо він укладений в умову (факт завантаження картинки). При цьому якщо дана «окрема частина» нам знадобиться лише один раз, краще виконати її просто як код (інклуд), а не як функцію. Функції завжди потребують деяких додаткових ресурсів. Те саме стосується і ООП-програмування в PHP. ООП-код споживає більше ресурсів, тому якщо вам не принципово ООП-форматування коду, краще відмовитися від нього. Я говорю саме про ООП-форматування, оскільки ООП-підхід у PHP має мало спільного із самим поняттям ООП-програмування. Як і PHP з класичним розумінням мов програмування та їх завдань – про що я писав на початку.

Ось ви ознайомилися з 7 основними принципами продуктивного коду на PHP. Це тільки — лише початок. Попереду ми ще багато цікавого, більш конкретного матеріалу з цієї теми.

Одним з основних критеріїв успішності будь-якого інтернет-ресурсу є швидкість його роботи і з кожним роком користувачі стають все більш вимогливими за цим критерієм. Оптимізація роботи php-скіптів – це один із методів забезпечення швидкості роботи системи.

У цій статті я хотів би представити на суд громадськості свою збірку порад та фактів щодо оптимізації скриптів. Збірка збиралася мною досить довго, заснована на кількох джерелах та особистих експериментах.

Чому збірка порад та фактів, а не жорстких правил? Тому що, як я переконався, немає «абсолютно правильної оптимізації». Багато прийомів і правил суперечливі і виконати їх неможливо. Доводиться вибирати сукупність методів, якими прийнятно користуватися без шкоди безпеці та зручності. Я зайняв рекомендаційну позицію і тому в мене поради та факти, яких Ви можете дотримуватися, а можете і не дотримуватися.

Що б не було плутанини, я розділив усі поради та факти на 3 групи:

• Оптимізація на рівні логіки та організації додатку
• Оптимізація коду
• Марна оптимізація

Групи виділені умовно і деякі пункти можна зарахувати відразу до кількох із них. Цифри наведені для середнього сервера (LAMP). У статті не розглядаються питання пов'язані з ефективністю різних сторонніх технологій та фреймворків, оскільки це тема окремих дискусій.

Оптимізація на рівні логіки та організації додатку

Багато порад і фактів, що належать до цієї групи оптимізації, є дуже значущими і дають дуже великий виграш у часі.

• Постійно профілюйте свій код на сервері (xdebug) та на клієнті (firebug), щоб виявити вузькі місця коду
  Слід зазначити, що профільувати треба і серверну, і клієнтську частину, оскільки не всі помилки сервера можна виявити на самому сервері.
• Кількість, що використовуються в програмі функцій користувача, ніяк не впливає на швидкість
  Це дозволяє використовувати в програмі незліченну кількість функцій користувача.
• Активно використовуйте функції користувача
  Позитивний ефект досягається рахунок того, що всередині функцій операції ведуться тільки з локальними змінними. Ефект цього більше, ніж витрати на виклики функцій користувача.
• «Критично важкі» функції бажано реалізувати сторонньою мовою програмування у вигляді розширення PHP
  Це вимагає навичок програмування сторонньою мовою, що значно збільшує час розробки, але в той же час дозволяє використовувати прийоми поза PHP.
• Обробка статичного файлу html швидше, ніж файлу php, що інтерпретується.
  Відмінність часу на клієнті може становити близько 1 секунди, тому має сенс чіткий поділ статики і сторінок, що генеруються засобами PHP.
• Розмір файлу, що обробляється (підключається) впливає на швидкість
  Приблизно на обробку кожні 2 Кб витрачається 0.001 секунди. Цей факт штовхає нас на проведення мінімізації коду скриптів під час перенесення на робочий сервер.
• Намагайтеся не використовувати постійно require_once або include_once
  Ці функції потрібно використовувати за можливості повторного зчитування файлу, в інших випадках бажано використовувати require і include .
• При розгалуженні алгоритму, якщо є конструкції, які можуть опрацьовуватися і їх обсяг порядку 4 Кб і більше, то оптимально їх підключати за допомогою include.
• Бажано використовувати перевірку даних, що відправляються на клієнта
  Це викликано тим, що під час перевірки даних за клієнта, різко знижується кількість запитів з неправильними даними. Системи перевірки даних клієнта будуються в основному з використанням JS і жорстких елементів форми (select).
• Бажано великі конструкції DOM для масивів даних будувати на клієнті
  Це дуже ефективний метод оптимізації під час роботи з відображенням великого обсягу даних. Суть його зводиться до такого: на сервері готується масив даних і передається клієнту, а побудова конструкцій DOM надається JS функцій. В результаті навантаження частково перерозподіляється із сервера на клієнт.
• Системи, побудовані на технології AJAX, значно швидше, ніж системи, що не використовують цю технологію
  Це викликано зменшенням обсягів виведення та перерозподілом навантаження на клієнта. На практиці швидкість систем з AJAX у 2-3 рази вища. Примітка: AJAX створює ряд обмежень на використання інших методів оптимізації, наприклад, робота з буфером.
• При отриманні post-запиту завжди повертайте щось, можна навіть пропуск
  Інакше клієнту буде відправлено сторінку помилки, яка важить кілька кілобайт. Ця помилка часто зустрічається в системах, що використовують технологію AJAX.
• Отримання даних із файлу швидше, ніж із БД
  Це багато в чому викликано витратами підключення до БД. На мій подив, величезний відсоток програмістів маніакально зберігають усі дані в БД, навіть коли використання файлів швидше та зручніше. Примітка:у файлах можна зберігати дані, за якими не ведеться пошук, інакше слід використовувати БД.
• Не здійснюйте підключення до БД без необхідності
  З невідомої мені причини багато програмістів здійснюють підключення до БД на етапі зчитування налаштувань, хоча далі вони можуть не робити запитів до БД. Це шкідлива звичка, яка коштує в середньому 0002 секунди.
• Використовуйте постійне з'єднання з БД за малої кількості одночасно активних клієнтів
  Вигода у часі спричинена відсутністю витрат на підключення до БД. Різниця у часі приблизно 0.002 секунди. Примітка:при велику кількість користувачів постійні з'єднання використовувати небажано. При роботі з постійними з'єднаннями має бути механізм завершення з'єднань.
• Використання складних запитів до БД швидше, ніж використання кількох простих
  Різниця в часі залежить від багатьох факторів (обсяг даних, налаштування БД та ін.) та вимірюється тисячними, а іноді навіть сотими, секунди.
• Використання обчислень на стороні СУБД швидше, ніж обчислення на стороні PHP для даних, що зберігаються в БД
  Це викликано тим фактором, що для таких обчислень на стороні PHP потрібно два запити до БД (отримання та зміна даних). Різниця в часі залежить від багатьох факторів (обсяг даних, налаштування БД та ін) і вимірюється тисячними та сотими секунди.
• Якщо дані вибірки з БД рідко змінюються і до цих даних звертається безліч користувачів, має сенс зберегти дані вибірки у файл
  Наприклад, можна використовувати наступний простий підхід: отримуємо дані вибірки з БД і зберігаємо їх як серіалізований масив у файл, далі будь-який користувач використовує дані з файлу. Насправді такий метод оптимізації може дати багаторазовий приріст швидкості виконання скрипта. Примітка:При використанні даного методу потрібно писати інструменти для формування та зміни даних файлу, що зберігається.
• Кешуйте дані, які рідко змінюються, за допомогою memcached
  Виграш часу може бути дуже значним. Примітка:кешування ефективне для статичних даних, для динамічних даних ефект знижується і може бути негативним.
• Робота без об'єктів (без ОВП) швидше, ніж робота з використанням об'єктів, приблизно втричі
  Пам'яті «з'їдається» також більше. На жаль, інтерпретатор PHP не може працювати з ОВП також швидко як із звичайними функціями.
• Чим більша мірність масивів, тим повільніше вони працюють
  Втрата часу виникає через обробку вкладеності структур.

Оптимізація коду

Дані поради та факти дають незначні порівняно з попередньою групою приріст швидкості, але у своїй сукупності ці прийоми можуть дати непоганий виграш часу.

• echo та print значно швидше, ніж printf
  Різниця в часі може сягати кількох тисячних секунди. Це викликано тим, що printf служить для виведення форматованих даних і інтерпретатор повністю перевіряє рядок на входження таких даних. printf використовується лише для виведення даних, яким потрібне форматування.
• echo $var."text" швидше, ніж echo "$var text"
  Це викликано тим, що двигун PHP у другому випадку змушений шукати змінні всередині рядки. Для великих об'ємів даних та старих версій PHP відмінності за часом помітні.
• echo "a" швидше, ніж echo "a" для рядків без змінних
  Це викликано тим, що у другому випадку двигун PHP намагається знайти змінні. Для більших обсягів даних розбіжності у часі досить помітні.
• echo "a","b" швидше, ніж echo "a"."b"
  Виведення даних через кому швидше, ніж через точку. Це пов'язано з тим, що у другому випадку відбувається конкатенація рядків. Для більших обсягів даних розбіжності у часі досить помітні. Примітка:це працює тільки з функцією echo, яка може приймати кілька рядків як аргументи.
• $return="a"; $return.="b"; echo $return; швидше, ніж echo "a"; echo "b";
  Причина в тому, що виведення даних потребує деяких додаткових операцій. Для більших обсягів даних розбіжності у часі досить помітні.
• ob_start(); echo "a"; echo "b"; ob_end_flush(); швидше, ніж $return="a"; $return.="b"; echo $return;
  Це зумовлено тим, що вся робота здійснюється без звернення до змінних. Для більших обсягів даних розбіжності у часі досить помітні. Примітка:цей прийом неефективний, якщо ви працюєте з AJAX, тому що в цьому випадку дані бажано повертати у вигляді одного рядка.
• Використовуйте «професійну вставку» або? a b
  Статичні дані (поза програмним кодом) обробляються швидше, ніж виведення даних PHP. Цей прийом називається професійною вставкою. Для більших обсягів даних розбіжності у часі досить помітні.
• readfile швидше, ніж file_get_contents , file_get_contents швидше, ніж require , а require швидше, ніж include для виведення статичного контенту з окремого файлу
  За часом зчитування порожнього файлу коливання від 0.001 до readfile до 0.002 для include .
• require швидше, ніж include для файлів, що інтерпретуються
  Примітка:при розгалуженні алгоритму, коли є можливість не використовувати файл, що інтерпретується, треба використовувати include , т.к. require підключає файл завжди.
• if (...) (...) else if (...) () швидше, ніж switch
  Час залежить від кількості гілок.
• if (...) (...) else if (...) () швидше, ніж if (...) (...); if (...) ();
  Час залежить від кількості гілок та умов. Необхідно використовувати else if скрізь, де це можливо, оскільки це найшвидша «умовна» конструкція.
• Найчастіші умови конструкції if (...) (...) else if (...) () треба поміщати на початку розгалуження
  Інтерпритатор переглядає конструкцію зверху вниз, доки знайде виконання умови. Якщо інтерпретатор знаходить виконання умови, то решту конструкції він не переглядає.
• < x; ++$i) {...} быстрее, чем for($i = 0; $i < sizeOf($array); ++$i) {...}
  Це викликано тим, що у другому випадку операція sizeOf буде виконуватися за кожної ітерації. Час різниці виконання залежить від кількості елементів масиву.
• x = sizeOf($array); for($i = 0; $i< x; ++$i) {...} быстрее, чем foreach($arr as $value) {...} для не ассоциативных массивов
  Різниця у часі значна і збільшується зі збільшенням масиву.
• preg _replace швидше, ніж ereg_replace , str_replace швидше, ніж preg_replace , але strtr швидше, ніж str_replace
  Різниця в часі залежить від обсягу даних і може досягати кількох тисяч секунд.
• Функції роботи з рядками швидше, ніж регулярні вирази
  Це є наслідком попереднього.
• Видаляйте вже непотрібні змінні масиви для звільнення пам'яті.
• Намагайтеся не використовувати придушення помилок @
  Пригнічення помилок виробляє ряд дуже повільних операцій, оскільки частота повтору може бути дуже великий, втрати швидкості можуть бути значними.
• if (isset($str(5))) (...) швидше, ніж if (strlen($str)>4)(...)
  Це викликано тим, що замість функції для роботи зі рядками strlen використовується стандартна операція перевірки isset .
• 0.5 швидше, ніж 1/2
  Причина в тому, що у другому випадку виконується операція поділу.
• return швидше, ніж global при поверненні значення змінної функції
  Це викликано тим, що у другий випадок створюється глобальна змінна.
• $row["id"] швидше, ніж $row
  Перший варіант швидше у 7 разів.
• $_SERVER[’REQUEST_TIME’] швидше, ніж time() для визначення часу запуску скрипту
  
• if ($var===null) (...) швидше, ніж if (is_null($var)) (...)
  Причина в тому, що у першому випадку немає використання функції.
• ++i швидше, ніж i++ , --i швидше, ніж i--
  Це спричинено особливостями ядра PHP. Різниця за часом менше 0.000001, але якщо у Вас ці процедури повторюються тисячі разів, то придивіться до цієї оптимізації.
• Інкремент ініціалізованою зміною i = 0; ++i; швидше, ніж ініціалізованої ++i
  Різниця за часом близько 0.000001 секунди, але через можливу частоту повтору слід пам'ятати цей факт.
• Використання змінних, що «відпрацювали», швидше, ніж оголошення нових
  Або перефразую інакше - Не створюйте зайвих змінних.
• Робота з локальними змінними швидше, ніж із глобальними, приблизно в 2 рази
  Хоч і різниця в часі менше 0.000001 секунди, але через високу частоту повторення слід намагатися працювати з локальними змінними.
• Звернення до змінної безпосередньо швидше, ніж виклик функції, всередині якої визначається ця змінна у кілька разів
  На виклик функції витрачається приблизно втричі більше часу, ніж виклик змінної.

Марна оптимізація

Ряд методів оптимізації практично не мають великого впливу швидкість виконання скриптів (виграш часу менше 0.000001 секунди). Незважаючи на це, така оптимізація найчастіше стає предметом суперечок. Я навів ці «непотрібні» факти для того, щоб ви в подальшому не приділяли їм особливої ​​уваги при написанні коду.

• echo швидше, ніж print
• include("абсолютний шлях") швидше, ніж include("відносний шлях")
• sizeOf швидше, ніж count
• foreach ($arr as $key => $value) (...) швидше, ніж reset ($arr); while (list($key, $value) = each ($arr)) (...) для асоціативних масивів
• Чи не коментований код швидше, ніж коментований, тому що йде додатковий час на читання файлу
  Дуже безглуздо зменшувати обсяг коментарів для оптимізації, треба просто в робочих («бойових») скриптах проводити мінімізацію.
• Змінні з короткими назвами швидше, ніж змінні з довгими назвами
  Це викликано скороченням обсягів оброблюваного коду. Аналогічно попередньому пункту треба просто в робочих («бойових») скриптах проводити мінімізацію.
• Розмітка коду з використанням табуляції швидше, ніж із використанням пробілів
  Аналогічно до попереднього пункту.

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

Якщо у Вас виникли питання, то для якнайшвидшого отримання відповіді рекомендуємо скористатися нашим

• Як оптимізувати сайт та прискорити його роботу?
• З якою швидкістю буде і може працювати сайт, відповідно до тих технологій на яких він буде запущений?
• Які технології слід використовувати налаштування сервера або VPS?

Типова проблема:
В якийсь момент сайт починає відкриватися та працювати надто повільно. Буває, що хостингова компанія блокує сайт за перевищення навантаження чи перевитрату ресурсів. Що ж робити у такій ситуації?

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

І якщо говорити про сервери для PHP, то такою проблемою є спосіб виконання php коду, як і інші значущі налаштування оточення на сервері.
Незалежно від того, чи є проблема у вашому коді чи її немає, висока у вас відвідуваність чи ні, від налаштувань сервера залежить дуже багато. Щоб все сказане не звучало порожніми словами і була написана ця стаття.

У цьому огляді я протестую щойно встановлений сайт на одному з найпоширеніших движків управління контентом Drupal 7.33.

Для тесту вибрано лише одну складову php-хостингу. Ми будемо тестувати web-сервери Nginxі Apache2, модулі mod_phpі php-fpm, версії php php53і php56, подивимося, як оптимізатори впливають apcі opcacheна швидкість роботи сайту

Звичайно, ці параметри лише частина налаштувань, від яких залежить швидкість сайту. Але ми навмисне
обмежуємося цим, щоб не робити огляд нескінченним.

Дано:

• Операційна система Centos 6.7
• Сервер баз даних: MariaDB 10.21
• Всі сесії сайтів зберігаються в memcache, щоб прибрати вплив швидкості встановлення сесії на швидкість роботи сайту.
• На всіх тестах як frontend виступає web-server nginx 1.93. У випадку з Apache2, Nginx виступає як балансувальник, а також для віддачі статики. У конфігураціях без використання Apache2 – безпосереднім web-сервером є Nginx
• Конфігурація Nginx і MariaDB містять безліч оптимізацій, спрямованих на досягнення максимальної продуктивності, але для всіх учасників тесту ці налаштування однакові і тому їх впливом слід знехтувати
• Параметри opcache та apc взяті з рекомендацій Bitrix, тому що вони оптимальні та універсальні для більшості сайтів

Як тестуватимемо?

У локальній мережі є сервер zabbix і його завдання щохвилини:

• Відкривати головну сторінку випробуваного сайту, чекати на певний вміст на сторінці, переконуватися, що відповідь від сервера - код 200.
• Наступним кроком йде авторизація в адмінку сайту, це відбувається відправкою відповідного запиту POST. Звірка тексту та коду відповіді на сторінці із закладеним еталоном. Цей крок стосується багатьох підсистем web-сервера, і багато в чому його швидкість залежить від швидкості взаємодії з базою даних
• Останнім кроком є ​​вихід з адмінки сайту, звірка коду відповіді та тексту на сторінці виходу
• За підсумками кожного кроку, zabbix буде скрупульозно заміряти і записувати швидкість рендерингу php-коду в html зрозумілий браузеру і демонструвати нам графіки отриманих результатів
• Для кожного випробуваного будуть записуватись значення протягом однієї години і як результат буде виступати середні значення за цю годину
• Тестування відбуватиметься всередині локальної мережі, тому вплив на результат швидкості інтернет-з'єднання виключено
• Для зручності сприйняття всі результати показую в порядку зростання. Тобто. найперший результат - це найповільніший. Всі конфігурації були винесені під умовний номер, що дозволить краще орієнтуватися в результатах
• Верхні графіки - швидкість генерації коду, що вище значення, краще. Нижні графіки - час відповіді сервера і чим нижче значення, тим краще
• Тестовані сайти живуть своїм життям, у них відбуваються регулярні операції з базами даних та виконуються завдання за розкладом, саме тому крива на графіках може мати злети та падіння

Тестування:

1. Nginx + php-fpm56 без оптимізатора opcache

По архітектурі - це один із найпередовіших варіантів. За продуктивністю – найбільше розчарування.

Продуктивність залишає бажати кращого, але навантаження такий варіант витримуватиме набагато краще, ніж варіант №2 з Apache2. Також такий варіант витрачатиме оперативну пам'ять суттєво ефективніше.

2. Apache2 + mod_php53 без оптимізатора apc

Найбільш типовий для хостингів варіант. 90% популярних хостинг-провайдерів використовують цей варіант. Хоча php53 давно не підтримується розробниками, але в інтернеті дуже багато сайтів, які досі працюють на цій версії.

Такий варіант не тільки дуже повільний, але й швидко падає під невеликим навантаженням через нестачу робочих процесів Apache2, або через нестачу оперативної пам'яті на сервері.

3. Балансування та статика через Nginx, динамічна частина Apache2 + mod_php56 без оптимізатора opcache

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

На жаль, далеко не всі сайти можуть працювати повноцінно із цією версією. Майже кожна нова версія PHP перестає підтримувати деякі застарілі та небезпечні функції, порушуючи роботу старого коду.
Сам собою php56 без оптимізатора досить повільний, а mod_php схильний падати і займати всю пам'ять на сервері під навантаженням.

4. Nginx + php-fpm53 без оптимізатора apc

Достатньо передова конфігурація, для тих хто не бажає мати проблеми через помилки з оптимізатором коду. При цьому використовується «сумісна» версія інтерпретатора PHP, а також зі зв'язки забирається ресурсомісткий Apache2.

5. Балансування та статика через Nginx, динамічна частина Apache2 + mod_php53 + apc

Ще одна поширена варіація. Дуже багато хостингів застосовують саме її, при цьому або використовують за умовчанням, або дають можливість включати оптимізатор у своїх панелях управління.
Зазвичай Apache2 залишають для роботи.htaccess-правил, таких як перетворення посилань та ЧПУ.

Отримуємо приріст швидкості у 3,5 рази, порівняно з варіантом без використання оптимізатора.
Сам по собі Apache (при використанні його власного модуля mod_php) витрачає на свою роботу набагато більше ресурсів, ніж варіант з php-fpm. Apache2 схильний падати, якщо в одному з його модулів відбувається збій або заповнювати собою всю оперативну пам'ять сервера.

6. Nginx + php-fpm53 + apc

Відмінний варіант для сайтів на старих двигунах, що не потребують складних.

Саме такий варіант я використовую, коли необхідно підняти застарілий сайт, домогтися від нього задовільної швидкості та надійної роботи при високих навантаженнях.

7. Балансування та статика через Nginx, динамічна частина Apache2 + php-fpm53 + apc

Варіант для застарілих сайтів із складними.htaccess. Наприклад – старі інсталяції Bitrix.

Це ідеальний варіант для застарілих веб-сайтів. Ця конфігурація стійка до високих навантажень, сумісна та досить продуктивна.
Відмінно підходить, коли потрібні правила.htaccess та додаткові модулі Apache2.
З недоліків - застаріла версія php, що не оновлюється, але якщо немає вибору - це найкращий варіант. Відмінно підходить для старої версій Bitrix, Joomla та інших поширених CMS не найсвіжіших версій.

8. Балансування та статика через Nginx, динамічна частина Apache2 + mod_php56 + opcache

Досить продуктивна, але ресурсомістка конфігурація з усіма недоліками mod_php.

Досить швидко, але під навантаженням у сервера може закінчиться пам'ять, а швидкість суттєво впаде.

9. Nginx + php-fpm56 + opcache

Найпродуктивніший варіант.

Це найкращий варіант для всіх сучасних веб-сайтів. Добре тримає навантаження, показує найкращий результат із погляду продуктивності. Саме такий варіант я використовую, коли постає завдання оптимізувати продуктивність сайту та збільшити швидкість його роботи.
Єдиний недолік - це те, що ми не зможемо використати. htaccess і всі правила mod_rewrite потрібно переписати на синтаксис Nginx.
Також не працюватимуть модулі Apache2. Якщо такі використовуються, цей варіант не підійде.

10. Балансування та статика через Nginx, динамічна частина Apache2 + php-fpm56+ opcache

Найкращий варіант для сайтів, де потрібний.htaccess. Ідеально підходить для нових версій Bitrix.

Добре тримає навантаження за рахунок php-fpm. Активно використовую цей варіант для більшості веб-сайтів.

Як підсумки:

• У реальному житті всі варіанти з Apache2 можуть бути повільнішими, так як у своїх тестах я навмисне передав віддачу статики Nginx. Це зроблено, щоб унеможливити вплив швидкості віддачі статики на результати виміру швидкості роботи інтерпретатора PHP. Однією з найбільш слабкою стороною Apache2 і при цьому сильною Nginx є швидкість віддачі статики. Особливо це помітно на високих навантаженнях. Крім того, Nginx менш схильний до атаки «повільних з'єднань»
• mod_php дуже швидко займає всю доступну пам'ять сервера та втрачає продуктивність на навантаженнях
• php-fpm витрачає пам'ять значно ефективніше, безпечніше та гнучкіше в налаштуваннях. У ряді випадків він швидший і без високих навантажень.
• Тест має тонку специфіку, тут ми побачили особливості роботи двигуна Drupal, інші можуть поводитися інакше, але загальна тенденція буде такою ж.

І головне – від конфігурації вашого сервера чи хостингу, залежить швидкість вашого сайту. Підібравши правильну архітектуру, ви можете отримати п'ятикратне збільшення швидкості роботи сайту.

Якщо у вас виникнуть питання, труднощі або потрібна порада:
Мої контакти у