Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Анализ логов Apache и поиск проблем с производительностью

drupal
performance
jmeter
apache
Теги: #<Tag:0x00007f7b627374d8> #<Tag:0x00007f7b62737370> #<Tag:0x00007f7b62737230> #<Tag:0x00007f7b627370f0>

(Александр Шиповалов) #1

Коллеги, добрый день. Столкнулся с таким новшеством, после проведения нагрузочного тестирования - от меня потребовали не отчеты, а собственно ответ в чем же состоит проблема. Заказчик, дал мне доступ к трем своим серверным машинам (Windows 2003), который предположительно (sic), образуют тестовый стейджинг. И находятся за балансировщиком нагрузки (к нему у меня доступа нет). Не могли бы вы подсказать, каким именно логи Apache 2.2 могут мне помочь в анализе проблем. Понятно что acces.log и error.log. Может быть есть какие то дополнительные инструменты и плагины - позволяющие снимать информацию с Apache. Само приложение представляет из себя Drupal “морду”, SQL (предположительно MySQL) и очень много сторонних API.


(Eugene Borodenkov) #2

При приведении тестирования вы снимали метрики с серверов которые нагружали?


(Александр Шиповалов) #3

Да конечно. Но только железа - процессора и оперативной памяти. С ними все в порядке.


(Максим Таран) #4

Мне, кажется, всё же, если это не было оговорено заранее, то это не ваша работа. Пускай разработчики разбираются. Вы же не собирали метрики с JVM, с базы? Такие вещи надо заранее обговаривать. В логах, скорее всего, вы ничего не найдёте, если специально нужную информацию туда не выводили/


(Александр Шиповалов) #5

Скажем, так меня больше интересует - могу ли я как посмотреть на что тратится время. Я вижу, что в среднем ответ от сервера возвращается за 3-и секунды. Посмотреть бы, на что они тратятся.


(Максим Таран) #6

Без дополнительного логирования и снятия метрик - нет. :smile:


(Александр Таранков) #7

Попробуй awstats, он вроде ничего был.
А какие проблемы выявились при тестировании? Что хочешь в логах искать?


(Александр Таранков) #8

Этого ты в логах вебсервера не увидишь.


(Александр Шиповалов) #9

Вот и хотелось бы понять куда и как рыть. Опыта в подобных изысканиях у меня нет. Но если хорошие заказчики, которые не раз шли нам на встречу, почему то предпочли попросить меня, а не удаленную команду разработки - я никогда не скажу, что это не моя работа.


(Александр Шиповалов) #10

Но насколько я вижу, awstats собирает статистику о посещениях?


(Александр Таранков) #11

Это правильная позиция. Однако, чтобы принести больше пользы (за более короткое время) хорошим заказчикам, лучше попросить у них контакты разработчиков, чтоб с ними напрямую взаимодействовать. Это сильно повысит эффективность

Вот туда и рыть, по компонентам. Для начала можно в профайлере браузера посмотреть Timing запросов - куда время тратится. Отсечь версию долгого рендеринга. Потом смотреть БД (через профайлер опять же) и взаимодействие с внешними API (чтоб не было много одинаковых запросов на странице, которые можно оптимизировать), через Fiddler, Wireshark и т.п.


(Александр Таранков) #12

Да, он смотрит по access.log статистику запросов к серверу и показывает статистику в динамике. Может когда-то пригодиться, но одним этим инструментом твою задачу не решить


(Александр Шиповалов) #13

Я вот и пытаюсь найти набор инструментов


(zub_test) #14

Есть вот такой модуль для апача: http://httpd.apache.org/docs/current/mod/mod_status.html (возможно понадобится помощь разработчиков, чтобы синтегрировать и настроить). Этот модуль даёт возможность мониторить состояние апача: сколько воркеров заняты, чем именно заняты, приблизительное rps, использование cpu, время обработки запросов и т.д… В общем много полезной информации. Мониторить нужно в runtime. Пример можно глянуть вот тут:
http://httpd.apache.org/server-status

Единственное: не отображает размер очереди. И пока я не нашёл, как это вообще можно сделать.

Чтобы узнать на что тратится время нужно будет ещё попрофилировать само приложение. Тут опять же понадобится помощь разработчиков.


(Александр Шиповалов) #15

Спасибо. Обязательно попробую.


(Александр Шиповалов) #16

Пока вроде бы увидел, что пиковая нагрузка на процессор доходит до 100%. А генерит ее php-cgi.exe. Несколько экземпляров которого болтаются в памяти? Кто нибудь сталкивался с такой прожорливостью php-cgi.exe и если да то как ее можно улучшить или хотя бы детализировать.


(Максим Таран) #17

Ну, насколько я понимаю - это и есть интерпретатор php. А какая часть сайта жрёт, тут уже надо рыть дальше.