Должен ли я пренебрегать Java Script при нагрузочном тестировании моего сайта?

Мы разрабатываем веб-приложение, которое должно выдерживать заметную нагрузку. Я провожу свои тесты на сервере HP (Proliant DL 380) (два процессора Xeon 3,6 ГГц, 16 ГБ ОЗУ, ...). Я использую Apache JMeter и pylot для запуска нагрузочных тестов (они вроде как показывают похожие результаты).

В одном сценарии я настроил программу нагрузочного тестирования так, чтобы она обращалась к моей индексной странице, используя только один поток, насколько это возможно. Индексная страница весит около 60 КБ и состоит примерно из 10 вызовов ajax, множества кодов JavaScript и jQuery, требуемого CSS и т. д. Результаты, которые я получил, были, ну, разочаровывающими.

Полная страница index.jsp:

  • Пропускная способность (треб/сек): 3,567
  • Время отклика (сек): 0,278

Поэтому я удалил каждый вызов ajax, избавился от диаграмм, а также CSS (но не JS).

  • Пропускная способность (треб/сек): 6,082
  • Время отклика (сек): 0,161

Еще очень мало! Поэтому я создал статическую индексную страницу в формате HTML, которая содержит все данные одинакового размера (без каких-либо вычислений на стороне сервера и на стороне клиента).

  • Пропускная способность (треб/сек): 20,787
  • Время отклика (сек): 0,046

Ого, это был прорыв! Теперь я добавил некоторые коды JavaScript на страницу index.html.

  • Пропускная способность (треб/сек): 9,617
  • Время отклика (сек): 0,103

Ну, я думаю, узкое место найдено, коды Java Script. Мне нужно выяснить, сколько запросов в секунду может обрабатывать «сервер», и, поскольку java Script запускается на стороне клиента, я не думаю, что мне следует включать его в этот тест. Так должны ли инструменты нагрузочного тестирования обрабатывать коды JS? (похоже они этим занимаются)

Другой ключевой вопрос: в зависимости от оборудования, размера контента и вышеупомянутых конфигураций, правдоподобна ли такая пропускная способность? Разве я не должен ожидать большего? мое ожидание 500 запросов/сек! это единственное решение, добавляющее аппаратное обеспечение?!

Кстати, веб-приложение было создано с использованием Java+Struts2+JSP+Hibernate+MySQL. он также распространяется по нескольким серверам с использованием haproxy. но вышеупомянутые тесты проводились на одном сервере.


java javascript stress-testing load-testing jsp
person SJ.Jafari    schedule 11.11.2012    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Ваш JavaScript (CSS, изображения) встроен непосредственно на страницу или загружается из тега скрипта? В последнем случае браузер загрузит файл с сервера, мгновенно уменьшив количество страниц в секунду вдвое. время загрузки страницы (необходимо сделать один дополнительный DNS-запрос), но действительно снимает нагрузку с вашего сервера

person thedayofcondor    schedule 11.11.2012
comment
Отличный момент! ну, некоторые из них встроены в страницу, а некоторые загружаются из тега скрипта. Но в приведенном выше тесте я вставил несколько пользовательских JS-кодов внутрь страницы, и это вдвое уменьшило потребность в секунду. - person SJ.Jafari; 11.11.2012
comment
Я не вижу, как выполнение javascript может замедлить работу ваших страниц — javascript, когда он загружается, встроенный в страницу, представляет собой просто текст — выполнение выполняется клиентом и вообще не должно влиять на сервер. Я думаю, что происходит то, что машины, которые вы используете в качестве клиентов, недостаточно мощны, чтобы запускать более 9,617 javascript в секунду, и это узкое место во время ваших тестов. - person thedayofcondor; 11.11.2012
comment
На самом деле ваш комментарий был ответом на мою дилемму: машина, на которой я тестировал, была недостаточно мощной, чтобы отправлять огромные запросы! - person SJ.Jafari; 17.11.2012

arrow_upward
2
arrow_downward

Если то, что вы ищете, является необработанным числом того, насколько быстро сервер может обслуживать контент, то я бы сказал «да», игнорируйте java-скрипт и сосредоточьтесь на том, насколько быстро требуется передать все различные биты страницы (HTML , изображения, файлы сценариев, CSS и т. д.).

Однако, если вы пытаетесь протестировать пользовательский опыт, JS является частью этого, поэтому вам нужно принять это во внимание. Судя по вашему описанию, вы не беспокоитесь о пользовательском опыте, а скорее загружаете сервер.

Возможно, вы захотите настроить JMeter для прямых вызовов частей ваших страниц, как описано в первом предложении выше.

person CodeChimp    schedule 11.11.2012
comment
Я согласен с вами по поводу JS, но я не думаю, что настройка JMeter для прямых вызовов страницы — это хорошая идея. Потому что есть также вызовы ajax, доступ к базе данных и т. д., которые необходимо учитывать. Одним из основных узких мест является процессор сервера приложений, который в этом сценарии будет заброшен. - person SJ.Jafari; 11.11.2012
comment
JMeter можно настроить для выполнения тех же вызовов ajax, что и браузер. Моя точка зрения была примерно такой: если вы хотите свести на нет JS как фактор, вам нужно исключить его из уравнения. Простейшим способом было бы просто делать любые вызовы (обычный HTTP, AJAX, WS), которые браузер делал бы при нормальных обстоятельствах. Преимущество использования JMeter заключается в том, что вы можете легко увеличить громкость после выполнения базовых тестов. Я ни в коем случае не хотел сказать, что это единственное решение, поскольку я уверен, что есть тысячи способов совершить тот же подвиг. - person CodeChimp; 15.11.2012

arrow_upward
1
arrow_downward

Другой ключевой вопрос: в зависимости от оборудования, размера контента и вышеупомянутых конфигураций, правдоподобна ли такая пропускная способность? Разве я не должен ожидать большего? мое ожидание 500 запросов/сек! это единственное решение, добавляющее аппаратное обеспечение?!

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

person troelskn    schedule 11.11.2012
comment
Ну, я думаю, что HAProxy делает это, и я поставил машину высокой доступности перед некоторыми бэкэндами Tomcat. Но, как я уже сказал, для простоты я провел тест только на одной машине. - person SJ.Jafari; 11.11.2012
comment
HAProxy не кеширует, это балансировщик нагрузки. Обычно вы помещаете кеш, такой как Varnish, Squid или nginx, перед HAProxy. Но вашему приложению по-прежнему необходимо разрешить работу кеша, отделив кешируемый контент от некэшируемого (частного) и создав правильные заголовки http для передачи этого в кеш. - person troelskn; 12.11.2012