Я настраиваю стек nginx и оптимизирую конфигурацию перед запуском. Запустив ab для стресс-теста машины, я был разочарован, увидев, что производительность достигает 150 запросов в секунду, при этом значительное количество запросов требует возврата> 1 секунды. Как ни странно, сама машина даже не тяжело дышала.
Я наконец подумал о том, чтобы пинговать коробку, и увидел время пинга около 100-125 мс. (Машина, к моему удивлению, стоит через всю страну). Итак, похоже, что в моем тестировании преобладает сетевая задержка. Выполняя те же тесты с машины в той же сети, что и сервер (время пинга <1 мс), я вижу> 5000 запросов в секунду, что больше соответствует тому, что я ожидал от машины.
Но это заставило меня задуматься: Как определить и сообщить о «реалистичном» количестве запросов в секунду для веб-сервера? Вы всегда видите заявления о производительности, но не следует ли учитывать задержку в сети? Конечно, я могу обслуживать 5000 запросов в секунду на машину рядом с сервером, но не на машину по всей стране. Если у меня много медленных подключений, они в конечном итоге повлияют на производительность моего сервера, верно? Или я все неправильно думаю об этом?
Простите меня, если это касается 101 сетевой инженерии. Я разработчик по профессии.
Обновить: Отредактировано для ясности.
Если вам важна производительность вашего сервера при доступе из любой точки мира, попросите друга где-нибудь в мире (должен иметь хорошую пропускную способность) установить sproxy + siege на его Linux-боксе. Просто скачайте, настройте, сделайте. Эти инструменты небольшие, они компилируются за секунды.
Во-первых, начало sproxy на коробке linux. По умолчанию он будет работать на порту 9001 на локальном хосте (127.0.0.1). Если вы хотите получить к нему доступ извне, просто передайте ему исходящий IP-адрес в качестве параметра.
Теперь подключитесь к sproxy, настроив ваш браузер на использование этого IP-адреса и порта в качестве прокси для HTTP. Все, что вы делаете с этого момента, записывается sproxy и может быть воспроизведено позже. Теперь просмотрите свой сайт, сделайте то, что делают ваши клиенты, и попытайтесь делать «дорогие» вещи, которые используют ваш сервер.
Когда закончите, закончите sproxy, нажав CTRL ^ C. Он записал ваши действия $HOME/urls.txt. Переместите файл туда, где находится siege. Чтобы начать стресс-тестирование, запустите siege -f urls.txt -d NUM -c NUM. d обозначает задержку между запросами, при выполнении тестов производительности используйте 1 (секунду). c обозначает количество смоделированных одновременных пользователей. Выбирайте по своему желанию, но начинайте с малого. Siege покажет вам количество транзакций в секунду, частоту ошибок, сколько времени занимали средние запросы и т.д. Это мощный и простой в использовании инструмент.
Если вам нужна дополнительная информация о параметрах (их много), проверьте руководство по осаде в sproxy руководство
Чтобы получить более реалистичные результаты, позвольте множеству людей одновременно протестировать ваш сервер из разных стран и позвольте им отправлять вам статистику.
Реалистичный показатель количества запросов в секунду следует брать из журналов доступа. IMO, задержка запроса не имеет ничего общего с нагрузкой на сервер, поскольку сервер обрабатывает все запросы с одинаковой скоростью независимо от их происхождения.
Рассмотрите возможность использования таких сервисов, как Soasta Cloudtest. С его помощью вы можете получать довольно подробные отчеты о своих тестах и запускать тесты производительности от различных поставщиков общедоступного облака / виртуализации. Вы можете настроить, насколько сильно и как долго вы хотите забивать свои серверы. У них также есть бесплатный "облегченный", чтобы вы могли увидеть, на что она способна, прежде чем вкладывать деньги.