2013-02-21 20 views
8

Ho ottimizzato il tempo di risposta della pagina su Tomcat e in quasi tutti i casi vedrò un tempo di risposta di 50ms se mi aggiorno più volte ma se la pagina non viene premuta per un secondo o due il tempo di risposta salta di nuovo a 500 ms.Latenza sporadica di Tomcat

Ho visto questo stesso comportamento a prescindere dalle risposte locali, non locali, APR, NIO, JIO, statiche o dinamiche (ad esempio servendo file statici o consegnando la risposta dinamicamente). Finora devo ancora vedere questo comportamento non accadere su Tomcat (che è costante sub 400ms indipendentemente dalla frequenza).

Ho usato Visual VM anche per vedere se c'erano indizi.

Ho pensato che fosse una specie di keep alive ma quando eseguo Apache Bench ottengo tempi di risposta ancora più veloci (sotto 50ms) (ovviamente perché lo si colpisce spesso).

Quindi, come mantenere una latenza bassa non viene colpito frequentemente l'URL in Tomcat? Forse questa domanda è meglio per ServerFault?

UPDATE: Sono quasi positivo è un problema di Tomcat 6. Pensavo di aver provato su Tomcat 7, ma l'ho appena testato e non ho avuto problemi (vedi i risultati sotto). Anche l'ultimo Tomcat 6 ha ancora questo problema.

Ecco la ab uscita per Tomcat 6 (notare il 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 

Ecco ab uscita per Tomcat 7 preavviso massimo:

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 

versioni La Tomcat sono l'unica differenza (stessa macchina, stesso JDK, ecc ...). Ho pensato che l'ultimo Tomcat 6 sarebbe andato bene, ma ha una latenza simile alla prima richiesta.

+0

Dipende molto da ciò che sta facendo la vostra richiesta. Stai semplicemente acquisendo un file .html o stai inizializzando una sorta di servizio dati, ecc. – aglassman

+0

Stai usando openjdk? Ho avuto alcuni problemi strani con lo swapping su Oracle JDK. – Jaydee

+0

Forse c'è un qualche tipo di GC completo che 'ferma il mondo' ... Hai controllato l'output di Garbage Collector (verbose GC)? – home

risposta

1

Sbirciando al codice tomcat ho deciso di cercare sulla parola "debole" sulla teoria che il tuo problema è che qualcosa in un riferimento debole viene raccolto quando non ri-richiesta rapidamente.

Sono venuto con la seguente congettura ... Ho trovato questo interessante Classe:

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

Sembra di mantenere una cache di BeanProperties oggetti, una parte dei quali è gestita da un WeakHashMap, e ogni volta che la cache si riempie, tutto viene messo in una WeakHashMap e può essere raccolto. Se vengono richiesti elementi nella mappa debole, vengono reinseriti nella mappa principale (che non è debole). Se la tua pagina scatta questo comportamento alla fine dell'elaborazione (causando qualcosa come la dimensione della cache in BeanProperties da aggiungere potresti finire per gettare via quasi tutte le descrizioni dei bean in cache.

Convenientemente c'è un proprietà per la sintonizzazione questo:

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

Così forse provare a giocare con questo e vedere se influenza il comportamento questo non potrebbe essere che tuttavia dato che non ho visto un grande cambiamento (rapido sguardo) in questa classe in Tomcat? 7 dove dici che il tuo problema scompare.(state modificando questa proprietà nei vostri sforzi di ottimizzazione precedenti?)