Tomcat sporadic latency

Question

Я оптимизировал время отклика нашей страницы на Tomcat, и почти во всех случаях я увижу время отклика 50ms, если я обновляюсь снова и снова, но если страница не попадает ни на секунду или два ответа время отклика обратно до 500ms.

Я видел это одно и то же поведение независимо от локального, а не локального, APR, NIO, JIO, статических или динамических ответов (т. Е. Для обслуживания статического файла или передачи ответа динамически). До сих пор я еще не видел этого поведения не происходит на Tomcat (это постоянный sub 400ms независимо от частоты).

Я также использовал Visual VM, чтобы узнать, есть ли какие-либо подсказки.

Я думал, что это какая-то жизнь, но когда я запускаю Apache Bench, я получаю еще более быстрое (менее 50 мс) время отклика (очевидно, потому что часто его ударяет).

Итак, как вы сохраняете низкую задержку, не часто попадая в URL-адрес Tomcat? Возможно, этот вопрос лучше для ServerFault?

UPDATE: Я почти уверен, что это проблема Tomcat 6. Мне показалось, что я тестировал Tomcat 7, но я снова тестировал его и не имел проблем (см. Результаты ниже). Даже последний Tomcat 6 все еще имеет эту проблему.

Здесь ab выход для Tomcat 6 (обратите внимание на макс):

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  0 0 0.0  0  0 
Processing: 14 39 45.2  30  314 
Waiting:  14 38 45.2  30  314 
Total:   14 39 45.2  30  314 

Здесь ab выход для Tomcat 7 уведомления макс:

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  0 0 0.0  0  0 
Processing: 25 38 8.8  37  67 
Waiting:  25 37 8.7  36  66 
Total:   25 38 8.8  37  67 

версии Кота единственная разница (одна и та же машина, тот же JDK и т. д.). Я думал наверняка, что последний Tomcat 6 будет в порядке, но у него есть аналогичная латентность при первом запросе.

Answer 1

Peeking at the tomcat code Я решил найти слово «Weak» по теории о том, что ваша проблема заключается в том, что что-то в слабой ссылке собирается, когда вы не запрашиваете запрос быстро.

я придумал следующее предположение ... Я нашел этот интересный класс:

http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/javax/el/BeanELResolver.java?revision=1027187&view=markup

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

Удобно, есть свойство для настройки этого:

private static final String CACHE_SIZE_PROP = 
    "org.apache.el.BeanELResolver.CACHE_SIZE"; 

Так может быть, попробовать играть с этим и посмотреть, если это влияет на поведение Это не могло бы быть это, однако, так как я не видел большие изменения (быстрый просмотр) в этом классе в Tomcat? 7, где вы говорите, что ваша проблема исчезает.(вы уже настраивали это свойство в своих предварительных настройках?)