Первый интересующий меня вопрос при тестировании был "какое количество соединений сможет отработать корректно апач на статическом контенте".
Начнём с того что отличительная фича работы apahce2 с запросами это возможность использования тредов. Напомню, что в 1-ой версии апач на каждое соединение делал fork процесса, во 2-ой ветке есть возможность собрать его со старой схемой обработки, но было бы глупо на продакшене не воспользоваться тредовой сборкой. Кому интересно можно почитать в официальной документации апача про
многопоточность и мультипроцессные модули. В моём варианте апач был собран с многопоточным модулем
worker.
Вопрос тюнинга немного не в топик, обсудим его позже подробно.
Ещё одно примечание - количество соединений, которое может отработать апач во многом ещё зависит от тюнинга ОС (в нашем случае это FreeBSD) об этом тоже отдельно.
Утилита, которой я тестировал называется
siege, она позиционриуется автором как стресс-тестер для веб-сервера, что как раз нам и надо. Скажу от себя что утилита вполне справляется со своим предназначением и была выбрана мной из-за простоты использования, гибкости и подробных отчётов.
Теперь о процессе тестирования. Для начала я заготовил файлы разного размера на веб-сервере (размер почти произвольный), я брал вариации маленьких файлов до пол-мегабайта и один больше 8 мегабайт (кеш на винте был 8 мегабайт); потом сгенерировал текстовый файл с ссылками. Прочитав мануал по siege настроил конфиг (командой siege.config можно создать темплейт конфига - .siegerc в домашней директории, откуда он и будет читаться).
Мои рекомендации по конфигу:
- переключить connection в режим close (keep-alive был по умолчанию) - как ни печально, но у меня siege не захотел нормально отработать keep-alive, с этим я ещё поразбераюсь и может что-то отдельно напишу;
- установить адекватный concurrent - это количество воображаемых пользователей "гуляющих" по ссылкам, которые генерирует siege;
- установить путь к файлу содержащему ссылки (если вы работаете больше чем с одним url) - директива file;
- установить время тестирования директивой time;
- рекомендую использовать директиву internet для рандомного перебора url-ами из списка (симуляция реальных запросов);
- timeout выбирайте на свой вкус, желательно чтоб он был согласован с таймаутом апача и был приближен к таймаутам браузеров.
Все опции можно задавать через ключи в командной строке, но чтоб не запутаться лечге прописать умолчания в конфиге.
В результате можно получить следующую интересную статистику:
- среднее время ответа сервера на запрос;
- среднее кол-во транзакций в секунду (отработанных запросов);
- пиковое кол-во одновременных запросов в секунду, после которого производительность апача начинает уменьшаться;
- процентное отношение корректно обработанных запросов к общему кол-ву запросов;
- кол-во необработанных запросов (не завершённых).
Публиковать свои результаты думаю не стоит, т.к. аппаратная и программная часть всё-равно у всех будет значительно отличаться. Может будут примеры к статьям о тюнинге самого апача и FreeBSD. Вообщем первая часть на этом заканчивается.
To be continued... :-)
