У меня есть веб-сервер на Linode 1024 VPS на основе
И еще пара блогов на основе WordPress 3.3.1. Один из них - обычный блог с конфигурацией по умолчанию, темой и просто сообщением «Hello World» для тестирования сервера. Другой - это блог, клонированный с другого сервера, с почти 10 тысячами сообщений и более чем 10 тысячами комментариев. Этот блог собирает около 5 тысяч уникальных посетителей в день.
Сервер дает хорошие результаты по тесту ab для тестовый блог, Но тот же тест с клонированным блогом сделать невозможно: тест ab слишком сильно загружает сервер, и мне приходится останавливать процесс, что в любом случае заставляет ab показать это действительно плохой результат.
Htop показывает также "нормальную" нагрузку в Нормальная операция, но аномально большая нагрузка во время теста ab.
Происходит еще одна странная вещь (для меня самая важная): время до первого байта чрезвычайно велико, но после этого подождите, сайт загрузится очень быстро. Это можно легко проверить с помощью таких сервисов, как tools.pingdom.com, что дает этот результат. Обратите внимание на эту желтую область, означающую «Время ожидания».
Почему это происходит? Возможные идеи:
Если кому-то нужна дополнительная информация,
Во-первых, это не ответ, а скорее диагностический подход.
Это ни в коем случае не исчерпывающе - или даже близко, это всего лишь отправная точка.
Время до первого байта
Время до первого байта (TTFB) состоит из нескольких компонентов:
Когда вы смотрите на вывод ApacheBench, вы также видите:
Сравнения для исключения компонентов
За некоторыми исключениями, ваша проблема будет заключаться в бэкэнд-обработке, которая обычно сводится к слишком сложному / неэффективному коду или плохо настроенному MySQL.
Хороший способ подойти к этой проблеме - провести серию сравнений, которые устранят различные аспекты вашей установки. Хорошее сравнение должно быть как можно более постоянным, чтобы помочь сузить проблему. В настоящее время вы предоставили следующие сравнения:
Идеальным тестом было бы продублировать весь сайт, а затем удалить все содержимое, кроме одной статьи и связанных с ней комментариев. Цель этого теста - окончательно определить, является ли проблема большим объемом контента или причиной являются другие аспекты вашей настройки (плагины WordPress, тема и т. Д.). По сути, вы сравниваете производительность идентичных сайтов на одном (новом) сервере - загружая одну и ту же страницу (такой же длины и т. Д.) - с той лишь разницей, что общее содержание сайта (например, есть большая вероятность, что какой-то плагин не хорошо масштабируется при увеличении содержания).
Ничего не меняя, вы можете сделать еще несколько сравнений:
Настройка вашего Backend
К этому моменту вы должны были либо найти проблему, либо сделать вывод, что она кроется в вашем сервере. Остается Nginx, PHP или MySQL.
(Я должен упомянуть здесь, что всегда полезно знать, является ли ваше узкое место ЦП, ОЗУ или ввод-вывод - между sar, top, iostat, vmstat, freeи т. д. вы сможете прийти к какому-то выводу по этому поводу.)
Nginx
Nginx просто принимает запросы и либо обслуживает статический контент, либо переключает запросы на PHP-FPM - обычно с Nginx особо нечего оптимизировать.
В идеале ваш тестовый блог и клонированный блог должны иметь идентичные конфигурации, и в этом случае вы эффективно устранили проблему Nginx.
заявка
В случае, когда вы пытаетесь определить проблему в своем коде (например, медленный плагин и т. Д.), Медленные журналы - это место для начала.
MySQL
PHP
PHP-FPM
Стоит отметить, что ваши результаты htop показывают, что php-fpm потребляет основную часть процессора - и ваша проблема, похоже, напрямую связана с этим.
Кеширование
После того, как вы оптимизировали каждое вероятное узкое место, начните кэширование.
Иногда, учитывая ограничения вашего приложения и оборудования, вы не можете так сильно улучшить производительность серверной части - однако это точка кэширования - чтобы минимизировать использование серверной части.
дальнейшее чтение