Название этого вопроса представляет мою основную озабоченность, но если вы продолжите читать дальше вопрос вы найдете некоторую предысторию нашей настройки .. которая может быть или не быть актуальной / полезной.
Мы проводим стресс-тестирование нашего приложения, используя Гатлинг, и запускаем сценарий Гатлинга на не замужем машина. Мы обнаружили, что наше приложение способно справиться с высокой нагрузкой, создаваемой инструментом стресса; однако он не справляется с относительно небольшой нагрузкой от реальных пользователей.
Мой вопрос: какая оптимизация или оптимизация на уровне ОС / сети происходит, когда параллельные запросы выполняются с одной машины / ОС в приложение, по сравнению с одновременными запросами с нескольких машин (то есть обычных пользователей, использующих свои веб-браузеры)?
У нас есть приложение Tomcat, которое находится за Apache через AJP, которое само находится за Citrix Netscaler через порт 80 (мы также планируем исключить Apache из уравнения, но это другое дело ...).
Наше приложение зависало при относительно низкой нагрузке (соединение CLOSE_WAIT между apache и tomcat), и мы находимся в процессе нагрузочного тестирования, чтобы решить эту проблему. Взаимоблокировки, возникающие в нашем экземпляре SQLServer, возникали довольно часто, поэтому мы решили начать с них. Чтобы воспроизвести проблему и впоследствии протестировать наши исправления, мы используем одну машину для генерации нагрузки с помощью Gatling.
Когда мы только начинали, мы могли надежно воспроизводить тупиковые ситуации с помощью этого инструмента. После некоторой оптимизации тупиковые ситуации исчезли, как и соединения CLOSE_WAIT. Затем мы запустили приложение в нагрузку, которая нам очень понравилась, и оно работало без каких-либо серьезных сбоев.
К сожалению, когда исправления были применены к производственной системе, мы все еще наблюдали то же исходное поведение. Это заставляет меня задуматься, не является ли нагрузка, создаваемая инструментом стресса, хорошим представлением того, что на самом деле происходит в реальном мире, из-за того, что он исходит из одного источника, а не из множества разных клиентов, разбросанных по Интернету.
Трудно оставаться в чем-либо, не увидев своего тестового сценария Гатлинга. Просто «слепой выстрел»: ваш тест Гатлинга неточно отражает реального пользователя, т.е.
Кеширование DNS. Gatling может поразить только один IP-адрес из-за IP-адресов, находящихся за кэшированием имен DNS на уровне JVM. Согласно Gatling FAQ:
По сути, DNS-кеш Gatling / JVM необходимо настроить. Решение - добавить
-Dsun.net.inetaddr.ttl=0в командную строку.
Запросы AJAX. Gatling не выполняет клиентский JavaScript, поэтому, если ваше приложение построено на запросах XMLHTTP, они не будут запущены, когда Gatling попадет на страницу. Вам нужно будет обработать их вручную, если ваше приложение использует какую-либо форму AJAX.
Поэтому я бы рекомендовал сослаться на Как сделать JMeter более похожим на настоящий браузер и реализовать эквивалентную настройку Gatling, как будто нагрузочный тест не представляет реальной нагрузки, нет большого смысла запускать такой тест.
Один генератор нагрузки, вероятно, лучше справится с пулом соединений, чем разрозненные клиенты; например, лучше использовать Keepalive. Это делает больше запросов при меньшем количестве подключений.
Если задействован циклический DNS, он будет иметь тенденцию затрагивать только одно из назначений DNS, а не распределять нагрузку по всем ним. Некоторые балансировщики нагрузки принимают решения о закреплении на основе IP-адреса клиента, который в этом случае будет статическим.
Ваш генератор нагрузки может иметь ограниченный пул выполнения (скажем, 200 «пользователей»), так что задержка в ответе заставляет пользователей замедляться, в отличие от реального мира, где у вас гораздо большее количество пользователей, которые не терпеливо ждут других пользователей доделать.