По-перше, це не відповідь, а діагностичний підхід.
Це аж ніяк не всебічне - або навіть щось близьке, це лише відправна точка.
Час до першого байту
Час до першого байту (TTFB) має низку компонентів:
- Пошук DNS: Знайдіть IP-адресу домену (можливе вдосконалення: більш численні / розподілені / чуйні DNS-сервери)
- Час підключення: відкрийте розетку до сервера, домовляйтеся про з'єднання (типове значення повинно бути приблизно в 'ping' час - зазвичай потрібна зворотна поїздка - keepalive має допомогти для наступних запитів)
- Очікування: початкова обробка, необхідна до того, як перший байт може бути надісланий (саме там має бути покращення - це буде найбільш важливим для динамічного вмісту.
Переглядаючи вихід ApacheBench, ви також бачите:
- Обробка: це сума очікування + повного перенесення вмісту (якщо час передачі значно більше, ніж очікується для завантаження кількості отриманих даних, відбувається подальша обробка (після першого отриманого байта)) (наприклад, сторінка промивання вмісту, як це доступно)
Порівняння для усунення компонентів
За невеликими винятками, ваша проблема полягає в обробці резервного копіювання, яка зазвичай зводиться до надмірно складного / неефективного коду або погано налаштованого MySQL.
Хороший спосіб підійти до цієї проблеми - через ряд порівнянь, які усунуть різні аспекти вашої установки. Хороше порівняння повинно тримати якомога більше постійних, щоб допомогти звузити проблему. На даний момент ви надали такі порівняння:
- Ідентичний (клонований) сайт, що працює на старому сервері та новому сервері:
- Різниця: Сервер
- Результат: старий сервер швидкий; новий сервер повільно
- Примітки. Тут вам потрібно визначити кількісні відмінності між цими серверами - як щодо використовуваного стека (Nginx, тощо), так і апаратного забезпечення (чи швидше старий сервер, оскільки він є більш потужною машиною?)
- Висновок: при правильному налаштуванні код може працювати швидко
- Тестовий сайт проти повного сайту на новому сервері
- Різниця: вміст, теми, плагіни тощо
- Результат: тестовий сайт швидкий, повний сайт повільний
- Примітки: теоретично цей тест повинен допомогти вам усунути багато аспектів вашого налаштування - DNS, мережу, навіть налаштування nginx / php / mysql - однак це не зовсім «справедливо».
- Висновок: додатковий вміст суттєво впливає на продуктивність
Ідеальним тестом було б дублювати повний веб-сайт, але потім видалити весь вміст, окрім однієї статті та пов’язаних із цим коментарів. Суть цього тесту полягає в тому, щоб остаточно визначити, чи є проблема великої кількості вмісту, чи є причиною інших аспектів вашої установки (плагіни WordPress, тема тощо). Ви по суті порівняли б продуктивність однакових сайтів, на тому ж (новому) сервері - завантажуючи ту саму сторінку (однакової довжини тощо) - з тією лише різницею, як загальний вміст сайту (наприклад, є хороший шанс, що якийсь плагін не виконає добре збільшується зі збільшенням вмісту).
Не змінюючи нічого, є кілька інших порівнянь:
- Тест із віддаленого місця та локального - це допоможе визначити, чи причина в мережі, затримка, dns тощо
- Ви вже (дещо) це зробили і здебільшого зробили висновок, що у вас немає проблем з мережею.
- Тестуйте через Varnish (тобто порт 80) проти nginx безпосередньо (порт 8080) - намагайтеся не змінювати конфігурацію між тестами - просто використовуйте правильний порт. Це покаже вам вплив лаку. Оскільки Varnish є шаром кешування, він повинен обслуговувати всі запити після першого, дуже важливо, він повинен обходити бекенд і обробку, необхідну для створення динамічної сторінки, і дуже швидко обслуговувати кешовану копію.
- Ви зробили це (хоча не локально) і продемонстрували, що лак має значний позитивний вплив на вашу ефективність.
Налаштування бекенду
До цього моменту ви мали б або знайти проблему, або зробити висновок про те, що вона лежить у вашій програмі. Це залишає вас Nginx, PHP або MySQL.
(Я повинен згадати, що це завжди зручно , щоб знати , якщо вузьким місцем є CPU, RAM, або I / O - між sar, top, iostat, vmstat, free., І т.д. , ви повинні бути в змозі прийти до якогось - або висновку з цього питання )
Nginx
Nginx просто приймає запити і обслуговує статичний контент, або переносить запити на PHP-FPM - зазвичай не так багато для оптимізації за допомогою Nginx.
- Встановити робітників = # процесорних ядер
- Увімкнути keepalive (значення 10-15 добре)
- Вимкнути непотрібні журнали
- При необхідності збільшуйте розміри буфера
- Уникайте, якщо оператори (використовуйте статичні назви замість регулярних виразів, де це можливо, усувайте непотрібні розширення)
В ідеалі ваш тестовий і клонований блог мають однакові конфігурації, і в цьому випадку ви ефективно усунули Nginx як проблему.
Застосування
У випадку, коли ви намагаєтесь визначити проблему у своєму коді (наприклад, повільний плагін тощо), повільні журнали - це місце для початку.
- Увімкніть повільний журнал MySQL та повільний журнал PHP-FPM запускайте ваш орієнтир і дивіться, що виходить як повільний.
MySQL
- Збільште кеші та запустіть mysqltuner.pl, щоб отримати хорошу вихідну точку.
PHP
- вимкнути непотрібні розширення,
- вимкнути register_globals, magic_quotes_ *, expose_php, register_argc_argv, always_populate_raw_post_data
- збільшити обсяг пам'яті
- open_basedir і safe_mode мають значні наслідки для продуктивності, але також можуть забезпечити додатковий рівень захисту. Тестуйте з ними і без них, щоб визначити, чи допустимий їх вплив на продуктивність.
PHP-FPM
- Відрегулюйте значення pm. * - збільште їх, щоб справлятися з великим навантаженням
Варто зазначити, що ваші результати htop показують php-fpm як споживаючу основну частину процесора - і ваша проблема, схоже, безпосередньо пов'язана з цим.
Кешування
Після оптимізації кожного можливого вузького місця, починайте кешування.
- У вас вже є кеш-код opCode (APC) - переконайтеся, що він працює (він постачається з тестовим файлом) - перевірте частоту звернень кеш-пам'яті та, якщо можливо, кеш APC-пам'яті замість диска.
- Налаштуйте свій код для кешування (наприклад, використовуючи плагін для Wordpress, наприклад W3TC)
- За допомогою nginx ви можете налаштувати кешування FastCGI - але оскільки у вас є Varnish, цього найкраще уникати.
- Налаштуйте шар кешування, такий як Varnish (який ви вже зробили) - і переконайтеся, що він працює (наприклад, використовуйте varnishstat, читайте Досягнення високого Hitrate )
- Додайте більше кешування для компонентів вашого сайту - наприклад, MemCched, якщо це можливо
Іноді, враховуючи обмеження програми та апаратного забезпечення, можливо, ви не зможете настільки сильно покращити продуктивність сервера, але в цьому полягає кешування - мінімізувати використання бекенда.
Подальше читання
if -fдирективою, яку ви використовуєте вlocationконтейнері в nginx config. Виходячи з того, що я читаю тут wiki.nginx.org/Pitfalls , у мене є відчуття, що-fце робиться неефективний пошук файлу, який може викликати проблему «Час до першого байту», особливо якщо у вас є каталоги з великою кількістю файли.