Tomcat sporadyczne opóźnienie

Question

Mikroskopijnie optymalizuję czas odpowiedzi strony na Tomcat i prawie we wszystkich przypadkach widzę czas odpowiedzi 50ms, jeśli odświeżam raz za razem, ale jeśli strona nie zostanie trafiona przez sekundę lub dwa czas reakcji powraca do 500ms.

Widziałem to samo zachowanie bez względu na lokalne, nie lokalne, APR, NIO, JIO, odpowiedzi statyczne lub dynamiczne (tj. Obsługa pliku statycznego lub dynamiczne przekazywanie odpowiedzi). Do tej pory mam jeszcze zobaczyć to zachowanie nie zdarzyć na Tomcat (czyli zgodne 400ms sub niezależnie od częstotliwości).

Użyłem programu Visual VM również sprawdzić, czy nie było żadnych wskazówek.

myślałem, że to jakiś utrzymać przy życiu, ale gdy uruchamiam apachebench mam jeszcze szybciej (sub) czas reakcji 50ms (oczywiście z powodu jej ukryć, że często).

Jak więc zachować niską latencję nie często hit URL w Tomcat? Być może to pytanie jest lepsze dla ServerFault?

AKTUALIZACJA: Jestem prawie pewien, że jest to problem Tomcat 6. Myślałem, że testowane na Tomcat 7, ale ja po prostu ponownie testowane na nim i nie mieliśmy problemu (patrz wyniki poniżej). Nawet najnowszy Tomcat 6 nadal ma ten problem.

Oto wyjście ab do Tomcat 6 (zauważyć max)

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 

Oto ab wyjście Tomcat 7 powiadomienia max:

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 

wersje Tomcat są jedyną różnicą (ta sama maszyna, ten sam JDK itp.). Myślałem, że najnowszy Tomcat 6 będzie w porządku, ale ma podobne opóźnienie na pierwsze żądanie.

Answer 1

wgląd do kodu tomcat postanowiłem poszukać na słowie „słaby” na teorii, że problemem jest to, że coś w słabym odniesienia są zbierane, gdy nie ponownie prośbę szybko.

wymyśliłem następujący odgadnięcia ... Znalazłem ciekawe Klasa:

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

Wydaje utrzymują bufor BeanProperties obiektów, z których część jest obsługiwane przez WeakHashMap i za każdym razem, gdy pamięć podręczna się zapełnia, wszystko jest umieszczane w WeakHashMap i może być zbierane śmieci. Jeśli żądane są elementy ze słabej mapy, są one umieszczane z powrotem na głównej mapie (która nie jest słaba). Jeśli strona wywoła to zachowanie na samym końcu przetwarzania (przez dodanie do niej czegoś takiego jak rozmiar pamięci podręcznej w BeanProperties, można zakończyć wykonywanie prawie wszystkich zapamiętanych opisów komponentów bean.).

Dogodnie nieruchomość do strojenia tym:

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

Więc może spróbować gry z tym i zobaczyć, czy to wpływa na zachowanie to nie może być to jednak, ponieważ nie widzę dużą zmianę (Quick look) w tej klasie w Tomcat? 7 gdzie mówisz, że twój problem znika.(czy ulepszyłeś tę właściwość w swoich wcześniejszych wysiłkach strojenia?)