Отчет о производительности сервлета: Сравнение производительности серверов J2EE

Оригинал статьи вы можете найти

https://www.webperformance.com/library/reports/ServletReport/

Кристофер Л Меррилл
© 2004 Web Performance, Inc; 7 июля 2004 г .; v2.3

Содержание

  • Вступление
  • Серверы
  • Цели тестирования
  • Тесты
  • методология
  • Журнал изменений
  • Результаты
  • Анализ
  • Будущие направления
  • Приложение 1: Resin
  • Приложение 2: Jetty
  • Отзывы и комментарии
  • История версий
  • Дополнительные материалы (материалы для скачивания)

Вступление

 

Если вы прочитали предыдущую версию нашего отчета, вы можете перейти непосредственно к разделу «Изменения», чтобы узнать, как изменилась наша методология тестирования для этой версии.

Стандартизация сервера приложений, благодаря спецификациям Sun J2EE, породила множество реализаций. Есть предложения от крупных игроков, таких как Sun, IBM, BEA и Oracle, а также многочисленные предложения от недорогих поставщиков и сообщества открытого исходного кода.

Как и большинство разработчиков, я участвую в ряде технических форумов и списков рассылки. Постоянная тема на форумах по разработке сервлетов: «Какой сервер J2EE я должен использовать для своего приложения на основе сервлетов?» Существует несколько критериев выбора сервера: простота установки, качество документации, надежность, стоимость и производительность. Некоторые из этих аспектов очевидны для оценщика; но производительность, кажется, вызывает много дискуссий с заметным отсутствием фактов. После быстрого поиска я был удивлен тем, что было опубликовано несколько полезных тестов, сравнивающих производительность сервлетов популярных недорогих серверов.

PECjAppServer2002

сервер для измерения производительности Java Enterprise Application Server с использованием подмножества API-интерфейсов J2EE в полном сквозном комплекте». веб приложение.” Подробная информация и результаты этого теста доступны на http://www.spec.org/jAppServer2002/. На мой взгляд, эта эталонная спецификация не имеет большого значения для небольших проектов, поскольку она не тестирует все серверы на одном и том же оборудовании, что искажает результаты для поставщиков, решивших финансировать экстравагантные конфигурации оборудования. С другой стороны, ориентир ориентирован на общую стоимость – транзакции на доллар инвестиций. Для больших реализаций это может быть очень ценной информацией. Было бы интересно протестировать этот тест в настройке, аналогичной этому отчету: все серверы, работающие в конфигурациях по умолчанию на одном и том же оборудовании. К сожалению, стоимость лицензирования SPECjAppServer2002 превышает наш бюджет.

Мотивация

Мое личное любопытство было движущим фактором, который инициировал эти усилия. Разработка и тестирование этого отчета финансируются исключительно нашей компанией как попытка внести свой вклад в сообщество Java, от которого мы так много получили.

отказ от ответственности и раскрытие информации:

  • Все заявления и мнения, сделанные в этом документе, принадлежат исключительно автору. Они не представляют взгляды и / или политики Web Performance, Inc.
  • Web Performance, Inc. использует Tomcat для запуска внутренней Wiki и некоторых наборов для тестирования.

Серверы

  • Apache Tomcat 5.0.25
  • IronFlare Orion 2.0.2
  • MortBay Jetty 4.2.20
  • Caucho Resin 3.0.8
  • IBM WebSphere 5.1
  • Macromedia JRun 4 (обновление 3)

Несколько серверов изначально предназначались для этого отчета, но результаты были скрыты, поскольку их лицензии запрещают публикацию тестов производительности без разрешения. Разрешение было запрошено у этих поставщиков, но разрешение еще не было предоставлено. Мы надеемся включить их в отчет вскоре после получения разрешения на публикацию. Эти серверы включают в себя:

  • Сервер приложений Sun Java System
  • Сервер приложений BEA WebLogic
  • Pramati Server

Отдельное спасибо

Я хотел бы выразить особую благодарность тем компаниям, которые не накладывают необоснованных ограничений на публикацию тестов производительности (Caucho, IronFlare и IBM). Открытый, информированный рынок выгоден для всех нас … включая конкурентов. IBM заслуживает особого упоминания за их очень четкое и очень справедливое положение о сравнительном анализе. Перефразируя, в лицензионном соглашении указывается, что показатели производительности могут быть опубликованы, если они сопровождаются полным раскрытием методологии тестирования. Кроме того, в нем есть «если вы сравниваете наш продукт, вы соглашаетесь, что мы можем сравнить ваш продукт». Я не юрист, но, на мой взгляд, это очень справедливый способ иметь дело с конкурентами, которые могут попытаться воспользоваться более гибким лицензионным соглашением.

Цели тестирования

Цель состоит не в том, чтобы объявить «победителя» – это лучше всего оставить публикациям, которые ищут доходы от рекламы. Вместо этого этот отчет предоставляет ряд различных измерений производительности сервера под нагрузкой. Данные представлены вместе с некоторым анализом и комментариями. Выбор победителя остается за читателем.

Сценарий использования

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

Трудности бенчмаркинга

Старая поговорка гласит: «Есть ложь, проклятая ложь и ориентиры!». Хорошо осознавая опасность ошибочных тестов, не стоит ожидать, что этот отчет будет отражать производительность любого конкретного приложения или класса приложений, которые могут быть развернуты в реальном мире. Любое данное приложение будет ударять по различным частям сервера. Некоторые приложения будут работать лучше на некоторых серверах, чем другие. Надеемся, что этот отчет предоставляет данные, которые помогают читателю взвесить компромисс производительности различных серверов.

Сырые числа против относительной производительности

Из-за изменчивости конфигурации приложений и оборудования этот отчет не может сказать вам, сколько пользователей сможет обработать ваше приложение в вашей среде (именно поэтому мы продаем продукт именно для этой цели!). В этом отчете будут отображаться такие числа, как число обращений в секунду и средняя продолжительность страницы, но необработанные числа сами по себе не имеют большого значения. Только когда статистические данные сравниваются с другими серверами, они дают ценную информацию для оценки производительности.

Некоторым это может показаться очевидным, но важно усилить этот момент: если данные для этого теста указывают на то, что Сервер X может обслуживать 200 ударов в секунду со средней продолжительностью менее 2 секунд, корреляции с количеством ударов / нет Сек, что ваше приложение будет в состоянии. Данные, представленные здесь для сервера X, полезны ТОЛЬКО для сравнения с данными для сервера Y и сервера Z при идентичных условиях тестирования нашей тестовой лаборатории. Кроме того, обратите внимание, что оборудование, используемое для сервера во время этих тестов (см. «Конфигурация оборудования» ниже), ни в коем случае не является современной конфигурацией.

Производительность из коробки

Полезно знать, как эти серверы будут работать сразу после установки. Большое количество проектов не имеет опыта или ресурсов для проведения обширной настройки производительности. Тесты выполняются на каждом сервере в их конфигурации по умолчанию после установки. (см. раздел «Методология»).

Воспроизводимые результаты

Независимо от того, как выполняется это тестирование, кто-то будет кричать “Грязная игра!” Основной целью этих усилий является тест, который легко дублируется любым, кто хочет попробовать. Без сомнения, точные цифры не будут дублироваться из-за различий в оборудовании и методике измерения, но относительные различия между серверами должны воспроизводиться. Все материалы, относящиеся к этому отчету, доступны в разделе «Дополнительные материалы».

Файл, содержащий подробную информацию о сценариях использования, создании сценариев тестирования и результатах теста, доступен здесь (20 МБ). Этот файл может использоваться с ознакомительной копией программного обеспечения для тестирования, Web Performance Trainer, для проверки этих деталей. Тем не менее, оценочная лицензия ограничена для моделирования 10 пользователей; поэтому на серверах нельзя получить значительную нагрузку с оценочной лицензией. Если у вас есть другие инструменты нагрузочного тестирования, результаты должны быть воспроизводимы в этих инструментах с информацией, которую мы предоставили. Если у вас возникли трудности с воспроизведением наших результатов, пожалуйста, свяжитесь с нами.

Сервлет Аспекты

Разумно ожидать, что разные серверы преуспеют в разных аспектах выполнения сервлета. Этот отчет включает в себя эти аспекты в тестах:

  • выполнение сырых сервлетов
  • статическая подача файлов
  • сеанса слежения
  • хранение и извлечение данных сеанса

Тесты

Пользовательские сценарии

Несмотря на то, что любой тест производительности может служить лишь приближением к реальному случаю использования, было важно выбрать пользовательские сценарии, которые хотя бы отдаленно похожи на тип использования, который будет типичным в рабочих развертываниях. Статистика сервера для нашего собственного сайта вдохновила нас. После детального анализа путей и страниц, которые просматриваются на нашем веб-сайте, были также проанализированы несколько общих веб-сайтов (Yahoo, Amazon и т. Д.). Для отчета были выбраны три пользовательских сценария:

сценарий продолжительность # страниц размеры страницы # ресурсы (изображения и т. д.) размеры ресурса (байты)
Короткий – отображает часто используемые страницы (например, домашние страницы и корпоративные порталы) и страницы с закладками, которые периодически проверяются 10 сек 1 60k 30 500 (x15)
2,500 (x10)
5,000 (x4)
10,000
Средний – представляет собой короткую операцию на веб-сайте (например, быстрый поиск товара или проверка статуса доставки на сайте электронной коммерции) 1 минута. 5 60k
40k
20k (x3)
50 500 (x27)
2,500 (x14)
5,000 (x4)
10,000 (x5)
Длинный – представляет длинные, вовлеченные операции на веб-сайте (например, размещение заказа и ввод информации об оплате и доставке) 3 мин 20 60k (x4)
40k (x4)
20k (x12)
125 500 (x72)
2,500 (x29)
5,000 (x4)
10,000 (x20)

 

Сценарии учитывают общее свойство веб-сайта: первая страница содержит много графики, многие из которых повторно используются на будущих страницах. Предполагая, что кеш в браузере включен, эти ресурсы больше не будут запрашиваться. Вот почему сценарий Short содержит 30 ресурсов на одной странице, а сценарий Medium содержит лишь немного больше ресурсов (50) на 5 страницах.

Распределение пользователей

На основании распределения, наблюдаемого в статистике нашего сервера, было выбрано распределение сценариев (ниже, посередине). Во время симуляции каждый виртуальный (симулированный) пользователь будет выполнять один и тот же сценарий несколько раз, до конца теста. После компенсации различий в длине каждого сценария можно рассчитать окончательное распределение пользователей (справа внизу).

сценарий распределение сценариев распределение пользователей
короткий 40% 5%
Средняя 35% 30%
Долго 25% 65%

Распределение пропускной способности

На общедоступных веб-сайтах и в интранет-приложениях заметно различаются распределения пропускной способности пользователей. Для общедоступных веб-сайтов типичны соединения от 56k до 1Mbit. Для приложений интрасети распространены от 10 Мбит до 100 Мбит (эта пропускная способность используется совместно). Для целей моделирования была выбрана полоса пропускания 1 Мбит на пользователя. Пропускная способность ограничена для каждого виртуального пользователя инструментом тестирования.

Обратите внимание, что при полосе пропускания на пользователя в 1 Мбит в сети 100 Мбит можно поддерживать не более 100 пользователей, используя их полную пропускную способность (при условии 100% эффективности сети – чего не может достичь Ethernet). Однако все сценарии содержат значительное «время обдумывания» (время между страницами), которое позволяет более 100 пользователям использовать полосу пропускания 100 Мбит. Ни один из серверов не был способен обеспечить полное насыщение пропускной способности сети – и, следовательно, не влияет на результаты теста.

Построение тестовых случаев

В этом тесте требуется сервлет, который может возвращать веб-страницы определенной длины и ссылаться на указанное количество внешних ресурсов (для этого моделирования используются изображения). Сервлет, используемый в тесте, обеспечивает необходимую функциональность, жестко запрограммированную в сервлете. Исходный код сервлета можно посмотреть здесь. После установки сервлета и необходимых ресурсов (через файл WAR) инструмент тестирования используется для интерактивной записи сценариев с помощью веб-браузера. Использовался Internet Explorer 5.5, но выбор браузера, используемого для записи сценариев, не должен влиять на тест. Каждый сценарий был записан в течение срока, указанного выше. Инструмент тестирования будет имитировать сценарий, используя то же время (задержка между страницами / URL-адресами), которое присутствует во время записи.

Сеанс-трекинга

Чтобы смоделировать, как контейнер сервлетов обрабатывает хранение и доступ к информации сеанса, тестовый сервлет использует объект сеанса (HttpSession). Чтобы эмулировать типичное приложение, объем информации в сеансе увеличивается с продолжительностью сеанса. На первой странице каждого теста начинается сеанс. Для каждой посещенной страницы генерируется случайная строка и добавляется в сеанс (HttpSession.setAttribute ()). Затем список атрибутов в сеансе просматривается, и каждый атрибут включается в возвращаемую страницу. Куки-файлы включены в браузере, так как это наиболее распространенное использование в реальных условиях.

Полный файл WAR, развернутый на серверах, доступен здесь.

Методология

Тестирование программного обеспечения

Тесты проводились с использованием Web Performance Trainer 2.7 (бета 5 – сборка 506).

Конфигурация оборудования

Поскольку каждый сервер работает на одной и той же машине, конкретное используемое оборудование не имеет значения. Но поскольку кто-то спросит: это сервер Dell PowerEdge 300 (850 МГц PIII, 512 МБ ОЗУ). Поскольку наиболее распространенным развертыванием для этих серверов будет Windows, серверы работают на Windows 2000 Server с пакетом обновления 2. Обратите внимание, что установщик Websphere предупредил нас о требовании запустить Windows 2000 с пакетом обновления 4. С тех пор сервер был обновлен и тест Websphere повторился – не было никакого видимого влияния на результаты.

Машины, генерирующие нагрузку, работают на нескольких компьютерах в нашей тестовой лаборатории под управлением Windows 2000 и XP. Все машины имеют 100 МБ Ethernet-адаптеры.

Генераторы нагрузки и сервер подключены через коммутатор Netgear FS524 Fast Ethernet. Во время тестов эта сеть изолирована от любых других сетей.

Установить, настроить и запустить сервер

Все серверы протестированы в конфигурации по умолчанию.

Если установочный пакет сервера связан с JVM, он используется. Если требуется использование внешней JVM, используется Sun JDK 1.4.2_03.

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

Когда сервер запущен, сервлет, используемый для тестирования, работает в течение одной минуты, чтобы проверить правильность конфигурации и убедиться, что сервлет был загружен и инициализирован перед началом каждого теста.

Запустите тесты

Тест выполняется линейно, добавляя 50 дополнительных виртуальных (смоделированных) пользователей через произвольные интервалы каждую минуту до завершения теста. Данные собираются и обобщаются средством тестирования с 10-секундными интервалами.

Конец теста

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

Измерение

Инструмент тестирования рассчитывает несколько показателей для каждого URL в тестовом примере, в дополнение к странице, сценарию и общей статистике теста. Эти статистические данные выбираются приблизительно с 10-секундными интервалами. Для простоты мы сконцентрируемся на одной странице в качестве показателя общей производительности в дополнение к нескольким общим статистическим данным тестирования.

  • Пользователи: количество моделируемых пользователей. Это контролируется программным обеспечением для нагрузочного тестирования.
  • CPU%: загрузка ЦП, предоставляемая Windows. Это значение является мгновенной выборкой в каждом периоде (что, как правило, делает его более шумным, чем другие показатели).
  • Хиты / сек. Количество HTTP-транзакций, успешно выполненных за период выборки.
  • Средняя продолжительность страницы: средняя продолжительность успешных транзакций веб-страницы (в частности, первая страница короткого сценария).
  • Ошибки: общее количество обнаруженных ошибок.

Обратите внимание, что из-за случайности, присущей тесту, и влияния выборки измерения, небольшой пик и впадины на графиках не имеют смысла. Общая тенденция – вот что важно.

Изменения по сравнению с предыдущей версией (v1.1)

Изменения с версии 1.1 до версии 2.0:

  • Использование сессионных объектов – см. Выше.
  • Ускоренная загрузка – нагрузка на сервер увеличивается быстрее: добавляется 50 новых симулированных пользователей в минуту, по сравнению с 20 в предыдущем тесте.
  • Более короткий период выборки – указанные выше изменения привели к тому, что каждый сервер достиг пиковой емкости намного быстрее (~ 10 минут против ~ 35 минут). В ответ мы сократили период выборки с 60 до 10 секунд. Более короткий период выборки может привести к более «изменчивому» графику, в зависимости от ответа сервера и присущей ему случайности в тесте.
  • Постоянные соединения – Соединения остаются открытыми и используются повторно для нескольких запросов, если они не закрыты сервером.
  • Несколько одновременных подключений – каждый виртуальный пользователь более близко эмулирует реальный браузер, открывая два одновременных подключения к серверу.
  • Производительность сервлетов не тестируется отдельно от производительности обслуживающих статических ресурсов – тестовый набор включает в себя и то, и другое.
  • Не допускается настройка / настройка производительности для любого сервера.

(просмотреть предыдущую версию отчета)

Результаты

Время загрузки страницы

На следующем графике показана средняя продолжительность страницы, измеренная для каждого сервера при возрастающей нагрузке. Вертикальная ось представляет время загрузки страницы в секундах. Это время включает в себя HTML из сервлета в дополнение к статическим ресурсам. Горизонтальная ось представляет время тестирования, которое пропорционально нагрузке на сервер (поскольку количество моделируемых пользователей увеличивается с постоянной скоростью 50 новых пользователей в минуту). Графики, которые остаются близко к горизонтальной оси, показывают лучшую наблюдаемую производительность под нагрузкой.

Tomcat, Orion, Resin и JRun работали очень близко к большинству испытаний. Орион сохранил показатели, аналогичные лидерам, но не выжил так долго. Tomcat и Resin продолжили шею и шею с немного лучшим временем отклика, чем JRun, который провел тест немного дольше. Производительность Jetty и Websphere снизилась в начале теста.

Количество ошибок

На следующем графике показано совокупное количество ошибок, зарегистрированных во время теста по вертикальной оси, со временем (нагрузка) по горизонтальной оси. Эти ошибки обычно являются отклонением соединения или непредвиденными ошибками закрытия сокета. Графики, которые поднимаются позже в тесте, указывают на лучшую устойчивость.

Tomcat и Resin снова были в шее и до шеи, пока почти 12-минутная отметка с JRun снова опередила их с небольшим отрывом. Орион превысил предел в середине пакета, а Jetty и Websphere превысили предел ошибок в начале теста.

Хиты/сек

Статистика Hits / Sec суммирует предыдущие две точки данных, измеряя количество успешно обработанных запросов за единицу времени. Вертикальная ось измеряет количество ударов в секунду, а горизонтальная отражает время (нагрузку). Более высокие графики представляют большую пропускную способность.

Большинство серверов показали очень похожую производительность на протяжении большей части теста. Websphere достиг максимума в начале теста. Причал не отставал от лидеров, пока не превысил предел ошибки, в то время как Орион продолжал масштабировать. Tomcat и Resin продемонстрировали пиковую пропускную способность выше, чем у конкурентов, хотя JRun внимательно следил.

Индивидуальная производительность сервера

Этот раздел содержит график нескольких ключевых параметров для каждого сервера:

метрический цвет трассировки масштаб
Загрузка (пользователи) синий От 0 до 1000 (пользователи)
пропускная способность красный От 0 до 1000 (попаданий в секунду)
ошибки желтый От 0 до 10000 (ошибки)
Загрузка процессора зеленый шкала от 0 до 100 (%)

Большинство серверов линейно масштабируются с нагрузкой, о чем свидетельствует сходство трассировки нагрузки и пропускной способности. Поскольку загрузка процессора достигает 100%, большинство серверов демонстрируют плато трассировки пропускной способности или нелинейное увеличение ошибок в ответ на постоянно увеличивающуюся нагрузку.

примечание: шкала времени для каждого графика отражает продолжительность теста для этого сервера. Каждый сервер работал в течение разного времени (см. Методологию).

Tomcat

Orion

Resin

Jetty

WebSphere

JRun

Анализ

Большинство серверов в этом тесте работали надежным, предсказуемым образом – хорошо масштабировались при увеличении нагрузки до пределов ЦП. JRun, Tomcat и Resin обыграли конкурентов за обработку пиковых ударов в секунду. Tomcat и Resin продемонстрировали более высокую пиковую пропускную способность и более низкое время загрузки страницы, чем JRun, что несколько пожертвовало этими показателями в пользу обработки большей нагрузки, чем другие. Jetty потребляла весь процессор немного раньше, чем лидеры, и показала значительно более высокое время загрузки страницы, так как приблизилась к пиковой емкости.

Jetty не использовала весь доступный ему процессор в конфигурации по умолчанию. Он был снова протестирован с конфигурацией, которая допускает больше потоков, результаты доступны в Приложении 2.

Orion также никогда не использовал полностью доступный ему ЦП, что заставило меня заподозрить, основываясь на результатах производительности предыдущей версии этого теста, что он будет конкурировать с лидерами, если конфигурация по умолчанию позволит обслуживать больше одновременных соединений. Эта теория была подтверждена добавлением <max-http-connections value = 100000> к конфигурации Orion, что позволило Orion пережить тест еще 90 секунд, приблизившись к производительности Tomcat и Resin. Поскольку это выходит за рамки руководства по тестированию, результаты не включены в этот отчет.

Websphere также не использовал полный процессор во время тестов, поэтому я подозревал, что он также способен повысить производительность. Я увеличил максимальный размер пула потоков (с 300 до 500). Это привело к значительному улучшению как времени загрузки страницы, так и пропускной способности. Тем не менее, ему все еще нужно больше настроек, чтобы догнать остальную часть пакета. Эта настройка выходит за рамки этого отчета.

Будущие направления

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

  • пулы ресурсов
  • SSL
  • другие операционные системы (например, Linux, Solaris)
  • оптимизация настроек сервера (потребуются некоторые добровольцы, имеющие опыт настройки каждого сервера)
  • сравнить производительность с другими JVM (IBM, BEA JRocket и др.)
  • отчет о полной производительности J2EE с использованием справочного приложения Java Adventure Builder

Приложение 1 – Resin config

Ряд читателей отметили, что в Resin есть очень простой вариант конфигурации, который может значительно повысить производительность. В файле смолы.conf измените значение параметра dependency-check-interval со значения по умолчанию, равного 2 секундам, на рекомендацию производителя, равную 600 секундам. После внесения этого изменения и повторения теста результаты отображаются на следующей диаграмме, которая показывает оба теста вместе:

Как видно из сходства приведенных выше графиков, влияние изменения этого параметра на производительность в данном конкретном случае незначительно. Из-за небольшого количества ресурсов в этом тесте по сравнению с крупномасштабным проектом неудивительно, что этот параметр не имеет никакого эффекта – ресурсов для проверки не так много.

Аналогично, результаты установки времени истечения срока действия кэша для статических ресурсов (включая файлы .png, используемые в нашем тестовом примере) не оказали заметного влияния на результаты теста.

Приложение 2 – Jetty config

После повторного тестирования Jetty с правильным файлом конфигурации стало очевидно, что Jetty был связан проектом, который никогда не позволял ему использовать всю доступную ему мощность процессора. Результаты показали, что загрузка процессора едва достигает 50%. Любопытно, что емкость Jetty, когда ему разрешено использовать весь процессор, была перенастроена на 150 потоков, как рекомендовали некоторые отзывы читателей. Даже с такой конфигурацией производительность Jetty значительно уступала конкурентам и все еще не использовала весь процессор. Затем Jetty был перенастроен на использование до 500 потоков. Несмотря на то, что он по-прежнему использовал не все доступные ему процессоры, это позволило Jetty выдержать увеличивающуюся нагрузку в течение времени, аналогичного показателям конкурентов, как показано в пересмотренной диаграмме пропускной способности ниже. Пропускная способность была ниже лидеров примерно на 20%, но показала, что она хорошо масштабируется, вплоть до своего предела.

Отзывы и комментарии

Комментарии об этом отчете могут быть размещены в блоге компании.

История версий

  • v3 – очистка электронной почты (23 января 09)
  • v2 – повторно протестировать Jetty с конфигурацией по умолчанию. Предыдущий тест ошибочно использовал файл конфигурации из тестирования v1.0. Помимо того, что он основан на файле конфигурации из предыдущей версии Jetty, он допускает практически неограниченное количество потоков.
  • v1 – добавить приложение 1 (6 июля, 04)
  • v0 – включает использование сеанса, постоянные соединения, более крутое наращивание нагрузки, несколько одновременных соединений (29 июня 04)
  • v1 – сделать номера версий более заметными (21 ноября 02)
  • v0 – первый публичный релиз (19 ноября 02)
  • v2 – внутренний обзор (15 ноября 02)
  • v1 – внутренний обзор (8 ноября 02)

Дополнительные материалы

Тестовый сценарий и результаты (2 МБ .wpt-файла (в архиве)) для использования с инструментом нагрузочного тестирования Web Performance Trainer

Исходный код для сервлета

Файл WAR, развернутый на серверах

Процесс установки и настройки для предварительной настройки каждого сервера