Как мне улучшить время отклика пристани? - PullRequest
Новая
       5

Как мне улучшить время отклика пристани?

5 голосов
/ 26 октября 2010

Я пытаюсь ускорить тестирование (чтобы сравнить его с использованием apache) для обслуживания динамического контента.

Я тестирую это с помощью трех клиентских потоков, запрашивающих снова, как только ответ возвращается.Они работают на локальном компьютере (OS X 10.5.8 MacBook Pro).Apache в значительной степени прямо из коробки (дистрибутив XAMPP), и я протестировал Jetty 7.0.2 и 7.1.6

Apache дает мне время spikey: время ответа до 2000 мс, но в среднем 50 мси если вы удаляете шипы (около 2%), среднее значение составляет 10 мс на звонок.(Это было на странице приветствия PHP)

Причал не дает мне пиков, но время отклика составляет около 200 мс.

Это вызывало местный хост: 8080 / привет /, который распространяется с пристани, и начинается с пристани с java -jar start.jar.

Это кажется мне медленным, и мне интересно,только я делаю что-то не так.

Буду признателен за любые предположения о том, как получить лучшие номера из Jetty.

Спасибо

Ответы [ 5 ]

18 голосов
/ 30 октября 2010

Ну, так как я успешно управляю сайтом с небольшим трафиком на Jetty, я был очень удивлен вашим наблюдением.

Итак, я только что попробовал ваш тест.С тем же результатом.

Итак, я декомпилировал сервлет Hello, поставляемый с Jetty.И мне пришлось посмеяться - это действительно включает следующую строку: 

 Thread.sleep(200L);

Вы можете увидеть для себя.

Мой собственный опыт работы с Jetty: я запускал многопоточныйнагрузочные тесты на моем реальном приложении, где у меня была производительность около 1000 запросов в секунду на моей рабочей станции dev ...

4 голосов
/ 16 октября 2012

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

Реалистичный трафик для веб-сервера - это не 3 очень загруженных соединения - 1 браузер откроет 6 соединенийтак что это представляет половину пользователя.Более реалистичный трафик - это сотни или тысячи соединений, каждое из которых в основном бездействует.

Прочитайте мои блоги на эту тему: https://webtide.com/truth-in-benchmarking/ и https://webtide.com/lies-damned-lies-and-benchmarks-2/

1 голос
/ 28 октября 2010

Вы обязательно должны проверить это с помощью профилировщика.Вот инструкции по настройке удаленного профилирования с помощью Jetty:

http://sujitpal.sys -con.com / node / 508048 / mobile

0 голосов
/ 28 октября 2010

Помните о компиляторе Hotspot.

Методы должны вызываться несколько раз (1000 раз?), Прежде чем они будут скомпилированы в собственный код.

0 голосов
/ 28 октября 2010

Ускорение или настройка производительности любого приложения или сервера на самом деле трудно сделать, по моему опыту.Вам нужно будет несколько раз сравнить с различными моделями работы, чтобы определить, какова ваша пиковая нагрузка.После того, как вы определите пиковую нагрузку для смеси конфигурации / среды, которую вам нужно настроить и протестировать, вам, возможно, придется выполнить 5+ итераций своего теста.Проверьте конфигурацию apache / jetty с точки зрения количества рабочих потоков для обработки запроса и, если возможно, их соответствия.Вот некоторые рекомендации:

  1. Рассмотрим различия двух сред (GC на пристани, рассмотрим настройку минимального и максимального порогов памяти для одного размера и позже приступим к выполнению теста)
  2. Нагрузка должна прийти из другой коробки.Если у вас нет второй коробки / ПК / сервера, учтите ваш ЦП / ядро ​​и настройте тест на конкретный ЦП, сделайте то же самое для jetty / apache.
  3. Это означает, что вы не можете заставить другую машину быть агентом стресса.Выполните несколько моделей рабочей нагрузки

Переходя к моделированию теста, выполните следующие 2 этапа:

  1. Один поток для каждой конфигурации в течение 30 минут.
  2. Начните с1 поток и увеличение до 5 с 10-минутным интервалом для увеличения счетчика,
  3. Основываясь на метрике Этап 2 определяет количество потоков для теста.и запустите это число потоков одновременно в течение 1 часа.

Соотнесите метрики (время отклика) из вашего приложения тестирования с сервером, на котором размещены ресурсы приложения (используйте sar, top и другие команды unix для отслеживания процессора).и память), некоторые другие процессы могут влиять на ваше приложение.(память важна для Apache Jetty будет ограничением конфигурации памяти JVM, поэтому она не должна изменять использование памяти, когда сервер запущен и работает)

...