У нас есть проблемы с производительностью на нашем сервере, которые могут быть, а могут и не быть неизбежным результатом высокого трафика на наши сайты. Мы хотели бы оптимизировать производительность каждого сайта, чтобы быть уверенным, что мы получаем максимальную отдачу от затраченных средств, прежде чем покупать дополнительное оборудование.
Мне было интересно, знает ли кто-нибудь о творческих способах измерения ресурсов (памяти, пропускной способности, процессорного времени и т.д.), потребляемых каждым веб-сайтом. Это может позволить нам выявить самых серьезных «нарушителей» и начать работать с ними первыми.
Мы используем Red Hat Enterprise Linux Server версии 5.6 (Tikanga).
Я бы начал с mod_log_config. Определите один или несколько LogFormat/CustomLog установки в httpd.conf используя только интересующую вас статистику и любые метаданные о запросах, которые вы хотите фильтровать, а затем вы можете быстро генерировать сравнительную статистику из этих файлов журнала. Например:
LogFormat "%t %v %B %D %h %r" statlog
CustomLog "|/usr/bin/cronolog logs/stat.log.%Y-%m-%d" statlog
%t это отметка времени, %v это имя хоста виртуального сервера, %B отправлено байтов (без заголовков), %D прошло микросекунды, %h это IP-адрес клиента, и %r это первая строка фактического HTTP-запроса, отправленного клиентом. Таким образом, вы можете оставить или удалить любую другую информацию, в зависимости от того, что вы ищете, или иметь один журнал для каждой характеристики, или что угодно. (Мне нравится использовать cronolog для ежедневной ротации журналов. -%H если вы хотите почасовую ротацию.)
Затем вы можете пропустить соответствующие столбцы с помощью любых вычислений, которые вы хотите получить, чтобы получить итоги, средние значения, выявить особенно медленные или оскорбительные страницы или что-нибудь еще.
Кроме того, если у вас есть mod_logio включен, вы можете получить точный количество байтов (после шифрования / сжатия / всего) для входящей и исходящей пропускной способности для каждого запроса с использованием %I и %O соответственно в вашем LogFormat строка.
Запуск suexec упростил бы просмотр того, какие пользователи используют больше ресурсов, поскольку их процессы php будут работать как их пользователи, а не как системный пользователь, запускающий apache, например www-data или nobody.
По моему опыту, magento - это ОГРОМНЫЙ ресурсоемкий ресурс, особенно если вы просто запускаете его в том виде, в каком он есть из коробки. Раньше мы, возможно, помещали пару умеренно загруженных сайтов в один ящик. С magento мы обнаруживаем, что размещаем один сайт на нескольких коробках.
Конечно, вы не хотите запускать magento, не пытаясь внести некоторые коррективы в производительность. Я настоятельно рекомендую вам установить memcached в качестве кеша для magento (инструкции Вот). и сохраните свои сеансы в кэше памяти и включите кеширование блоков. (Это будет принимать html, который создается отдельными блоками, и сохранять его в memcache, чтобы при следующем доступе к тому же блоку файлы phtml не запускались снова).
Возможно, вы захотите запустить ускоритель кодов операций, например APC, для кэширования кодов операций PHP.
Обновить:
Вы определенно хотите убедиться, что mysql настроен, особенно если у вас достаточно буферного пула innodb. (все таблицы magento - innodb). Я думаю, что хорошее место для чтения о настройке производительности mysql - это блог о настройке производительности mysql. Я бы начал с настройка innodb_buffer_pool_size. Обратите внимание, что они обычно говорят о запуске mysql на сервере, который ничего не делает, кроме запуска mysql, поэтому, когда они говорят «выделить 12 гигабайт на 16-гигабайтном блоке для innodb_buffer_pool», вы должны отрегулировать это значение вниз, поскольку ваш бокс делает больше, чем просто mysql.
Я всегда запускаю collectl на всех серверах. Он отбирает тонны метрик каждые 10 секунд и данные slab / process каждую минуту и записывает все это в файл, который вы можете воспроизвести ИЛИ построить график с помощью colplot (часть collectl-utils). Вы также можете запускать его в режиме реального времени с любым интервалом выборки по вашему выбору.
Основываясь на том, что вы видите в течение нескольких часов или даже дней, вы можете начать применять подход, очень четко сформулированный apaptr, - сначала выяснить, есть ли проблема, а затем предпринять шаги для ее устранения. Собирая данные на каждом этапе процесса, очень легко определить, улучшилось ли положение или ухудшилось.
-отметка
Вы начинаете не с того конца.
Традиционно (и тоже разумно!) Вы НАЧИНАете с определения реальной проблемы; затем вы переходите к диагностике его причин и только ЗАТЕМ добавляете оборудование или изменяете конфигурацию программного обеспечения.
Если прямо сейчас возникает реальная, наблюдаемая проблема, с этого следует начать: постарайтесь точно определить, при каких обстоятельствах она возникает, воспроизводима ли она в точности, и предположите, какое влияние она оказывает на бизнес.
Затем начните сбор данных о производительности из вашего стека приложений; это может включать, но не ограничивается: использование ресурсов ОС, метрики веб-сервера, кэширование PHP, базы данных, дисковый ввод-вывод и задержка.
Прошу прощения, если ответ кажется расплывчатым или общим - вопрос был таким.