Напечатанные ab результаты узла, кластера и nginx, нечетных результатов?
Можно автоматизировать некоторые шаги с помощью сценариев оболочки. Например, можно включать инструменты/пакеты, которые будут установлены. Для находящихся в debian систем Вы можете та apt-get install команда.
Можно использовать ту же схему разделения для общих разделов на всех серверах. Связанные с сервисом разделы должны быть настроены и зарегистрированы.
Можно записать все эти шаги в документе и следовать за ним при выполнении установки.
Это вопрос интерпретации. Вы не делаете ничего плохого. Вот как я интерпретирую график. Это график распределения x vs y, где:
- y - время ответа в мс,
- x - количество запросов, возвращенных в течение y мс кумулятивно.
Утверждения, основанные на распределении запроса для узла (отдельно ) будет:
- 7000 из 10000 запросов были возвращены в течение ~ 14 мс
- 2000 из оставшихся 3000 запросов были возвращены в течение 14-18 мс
- 800 из оставшихся 1000 запросов были возвращены в течение 18-22 мс
- Остальные 200 были возвращены в течение 35 мс
. Но при совокупном анализе это будет:
- 7000 из 10000 запросов были возвращены в течение 14 мс
- 9000 из 10000 запросов были возвращены в течение 18 мс
- 9800 из 10000 запросов были возвращены в течение 22 мс
- Все были возвращены в течение 35 мс
Конфигурация кластера покажет более быстрые результаты, чем один узел, как ожидалось.
Для результатов nginx будет фиксированная задержка в обработке / балансировке нагрузки. Глядя на рисунок, это будет задержка около 9-10 мс, что вполне ожидаемо. Это не означает, что конфигурация nginx плохая. Он действительно возвращает большинство запросов в течение 30 мс (небольшое отличие от других конфигураций).
Вы указали количество одновременных запросов как 1000 в Apache Bench, что не требует большой балансировки нагрузки, поскольку даже один узел легко справляется с такой большой нагрузкой. Предоставление большего количества одновременных подключений / более тяжелой обработки для каждого запроса взорвет график для одного узла (он поднимется раньше для меньшего количества запросов). Nginx жертвует небольшим временем обработки, чтобы обрабатывать большее количество одновременных запросов, сохраняя при этом разумное время ответа.