ab, выбор стратегии нагрузочного тестирования

[fisher]

ab, выбор стратегии нагрузочного тестирования

два вопроса по subj
1) существуют ли какие-то полукачественные оценки того, при каком маскимальном числе одновременных запросов можно выполнять тесты на сервере, т.е. пускать ab на той же машине, на которой живет веб-сервер, не вынося их на отдельного клиента? понятно, что этого лучше не делать, поскольку сервер будет нагружен и как клиент, но всё-таки. речь идёт о диапазоне в 1-1000 параллельных запросов и о получении в первую очередь качественных (не количественных) оценок производительности при изменении тех или иных параметров. или это все децкий сад и надо по-любому разносить?
2) для полной чистоты эксперимента при сравнительном тестировании нескольких скриптов, выполняющих одну и ту же задачу разными способами, надо бы после каждой порции тестов перезапускать сервак. насколько целесообразен такой параноидальный вариант? или все-таки достаточно перезапустить основные сервисы (базу, апач) ? что необходимо помониторить, чтобы выбрать правильную стратегию?

 

[Screjet]

1) Тестирую всегда на локалхосте. Затратами системы на саму утилиту и лупбэк (имхо) можно принебреч.
2) А зачем перезапускать? В реальной системе разве чтото перезапускается в процессе работы?

 

[fisher]

2Screjet
1) для нескольких параллельных запросов - да, а для тысяч? вот в этом и состоит вопрос
2) если для одной серии "вдруг" были спровоцированы прямо или косвенно утечки, появились зомбаки и т.д - для последующих статистика будет абсолютно некорректной.

посему и стал вопрос - есть ли какие-то качетственные оценки, как сделать наиболее простым и в то же аремя корректным "тестирование без оператора", когда скажем есть сотни наборов параметров, на которых надо пару-тройку ночей погонять.

 

[neko]

разносить разумеет надо, только если тебе интересуют запредельные нагрузки ("а когда интересно оно упадет?"), а не просто "за сколько времени"

я разношу, когда базы теструю, правда там ни php ни апач не учавствуют

надо бы после каждой порции тестов перезапускать сервак. насколько целесообразен такой параноидальный вариант?

зачем? кеш сбросить? и если да, то надо думать чей именно.

-~{}~ 06.08.04 23:11:

с локалхоста вообще никогда не тестирую кстати
искажения неизбежны

 

[Screjet]

..хм.. Сколько же твоя система ожидает хитов? Миллион в час? ..или больше


Скажу из опыта: сколько бы ты не тестировал, какие бы тесты не придумывал, люди начнут юзать твою систему и ты обнаружишь совершенно "непонятные" глюки, диапазон которых может начинаться от ОСи и заканчиваться твоими скриптами. Например, многие ли знают, что у мускула по дефолту разрешено 100 коннектов, а ОСь, по дефолту, в среднем, позволяет держать около 1000 открытых дескрипторов, а ПХП очень тяжелый изза чего возникают "гонки". Причем такого рода приколов = валом!

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

 

[neko]

я бы не мешал в кучу глюки и ресурсоемкие операции

кроме того не надо путать тестирование конкретного скрипта на предмет оптимизации и тестирование на усточивость сервера в целом

вобщем не надо понятия подменять

по поводу скорости работы theta join в версии А субд Б с сисадмином тоже советоваться бесполезно

 

[Silent]

Небольшое предупреждение (может это только мне так "повезло", но все же):

решил как то задействовать ab на локальной машине под WinXP (ab брался из поставки второго Апача под Вин). И один мой скрипт стал выдавать от 5 до 80 процентов failed requests. При детальном рассмотрении оказалось, что Апач получал 100 запросов, скрипт сто раз отрабатывал, Апач сто раз выдавал код ответа 200 (все это видно из логов), а ab при этом показывал 80 процентов failed requests. Дело было в том, что длина тела документа отличалась на один-два байта и ab считал, что запрос не прошел, вообще не обращая внимания на код ответа. Может это быт глюк конкретной версии ab, но в любом случае с ним нужно быть осторожнее.

 

[fisher]

2Silent: звучит странно, но спасибо за предупреждение. я так полагаю, что ты говоришь о тестировании risearch скриптов ? если есть желание поделиться результатами тестов - я их мог бы включить в обзорную часть своего доклада по поисковым делам, в которой в любом случае risearch упомяну. собственно, сейчас я как раз гоняю тесты именно поисковых скриптов.

если бы ещё кто-то из "админов" принял участие в дискусии... а то пока в-основном, извините, пустой трёп на уровне "надо подумать", "всё сложно" и "посоветуйся со специалистами" специалисты, ау

 

[fixxxer]

тестировать на винде надо на первом апаче, который честно форкается.

 

[Silent]

fisher

Да я там ничего особенно не тестировал. Поиск он по определению является тяжелой операцией, и я никогда стресс-тесты не ставил. Если поиск является основным сервисом на сайте, то там скорее всего будет стоять более серьезный движок, а если поиск всего лишь вспомогательный сервис, то вряд ли там в реале будет по несколько запросов в секунду.

Просто на одном форуме мне сказали, что RiSearch падает через раз и посоветовали погонять его с помощью ab. Вот я и погонял. Действительно "падал" через раз. Стал выяснять, в чем причина, а оказалось, что скрипт просто показывает время поиска, которое мне было лень отформатировать и поэтому строка со временем могла занимать 4, 5 или 6 байтов. Следовательно и выдача скрипта отличалась длиной на один-два байта при каждом запросе, а ab считал это ошибкой.

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


fixxxer
Я и тестировал на первом Апаче, просто ab пришлось взять из второго, в первом его вроде не было (в Вин версии). Но в любом случае, тестировать нужно на таргет-платформе, а в Виндовс можно только примерно оценить время отклика. На относительно легком запросе поиск отвечал на несколько запросов в секунду в режиме CGI и пару десятков запросов в mod_perl, что мне кажется вполне достаточным.

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

 

[fisher]

2silent: понятно. вообще тесты конечно стоит погонять я сейчас тестирую не столько c целью получить количественные харатектеристики, сколько оценить поведение несколькиз разных методов хранения и поиска (леммы vs оригинальные формы, ну и некоторые другие чисто технические приёмы). но тут другая специфика - все сортировки возложены на базу, что в общем случае сосёт, и основная задача - понять когда оно сосет больше, а когда меньше

-~{}~ 11.08.04 18:23:

век живи - век учись, помрешь дураком! silent прав: ab считает request к нестатической странице failed если они отдают разный контент. но это можно просто игнорировать.