LINUX.ORG.RU

[LAMP] бенчмаркизация, профилизация, бутылкогорлодетектизация

 


0

0

Господа, кому не жалко — поделитесь информацией о том, как кто тестирует производительность своих веб-проектов. Интереса праздного ради.

Установка: есть машинка, на машинке Apache2 + mod_fcgid + PHP 5.2.11 + MySQL 5.1. И есть там две ветки одного и того же проекта, в одной ветке то, что и у клиентов на продакшене, во второй ветке то же самое, но с преферансом и поэтессами в части уменьшения нагрузки и увеличения быстродействие.

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

Вторая часть балета — это сделать профилировку и автоанализ полученных данных, чтобы мне было по результатам сказано: у тебя вот здесь, здесь и здесь есть вызовы функций, выбивающиеся из общей картины настолько, что с этим надо что-то делать. Ибо корпеть над ручным сбором и сидением с KCacheGrind не очень спортивно.

★★★★★

Меня устраивает следующая схема на 99%:

gentoo

xdebug расширение (на сайте есть подробные инструкции)

kde-base/kcachegrind

app-benchmarks/siege

kcachegrind дает очень подробную информацию на основании дампа xdebug. Неудобство в том, что xdebug будет слегка "подтормаживать" на профилировке, соответственно нужно делать поправку времени на тесты и естественно xdebug нельзя оставлять в продакшене. В этой связке я добился следующих цифр: до оптимизации 200-300 "относительных тиков", после 150, с APC <=95-100. Меньшая цифра означает затраченное время в относительных величинах.

Здесь рассматриваются подробно вопросы оптимизации: http://talks.php.net/show/froscon08/8

swwwfactory ★★
()
Ответ на: комментарий от swwwfactory

Ну, скажем так, я использовал все это. В ручном режиме, при живой отладке — красота. Но теперь надо взять тот же siege, и гонять его с юзерами от 1 до 100 по 10 минут, после чего выстроить график отклика системы, чтобы видеть, когда она начинает тормозить, когда начинает тормозить жутко, и когда, наконец, теряет стабильность.

Все это делается на одной версии проекта, а затем на другой при прочих равных условиях.

После этого из полученной статистики siege делаются два сравнительных графика. Все это показывается начальству со словами «я, лять, недаром тут плюшки жрал с казенным кофем!»

shimon ★★★★★
() автор топика
Ответ на: комментарий от shimon

Безусловно, siege лучше всего подходит для нагрузочных тестов без авторизации. Но там можно настроить логи, потом соответственно парсить... В случае тестов с авторизацией: куки, урл с сидом. Далее, заготовить сессионные урлы(/+/-/куки) и по ним прогнать siege + логи через watch, inotify-tools, filemon(fam) или подобные утилиты

Есть еще неплохой инструмент: selenium. Позволяет программно "имитировать" работу браузера... Через API selenium можно вытянуть "авторизованный" урл, который пойдет уже на siege.

swwwfactory ★★
()
Ответ на: комментарий от anonymous

> А кстати почему так, а не mod_php?

Потому что на продакшене так точно же. И секьюрнее, ввиду того, что это типа хостинг, а на хостинге suexec.

shimon ★★★★★
() автор топика

По первой части задачи - jMeter: можно делать сложные сценарии, графиков до фига, и много всего (но придется осилить доки).

Нагрузочное удобно проводить на Amazone - делается AMI с необходимой конфигурацией jMeter, далее запуск N инстансов, снимаем показатели и переходим к следующему шагу.

oc
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.