Newsgroup: it.comp.java
Titolo: Servlet Out of Memory

Buon giorno a tutti,
vorrei sentire un po'le Vostre opinioni su di un problemino riguardante le
Servlet.
Abbiamo da poco aggiunto al nostro sito una Servlet per gestire un po' di
back-end
dati- utilizziamo come piattaforma Apache-JServ su Linux su di un Pentium
con 512 RAM.
Il problema č che la Servlet va in Out of memory quando il numero dei
clienti da servire supera i 150-160 in contemporanea. Il problema potrebbe
essere il garbage Collector dell' 1.2 , non del tutto efficiente, allora
abbiamo provato installando il Jdk 1.3- le cose vanno un poco meglio- il
numero degli accessi consentiti sale, comunque oltre i 160 la CPU occupata
arriva quasi al 100%.....
Volevo sentire un poco cosa ne pensate- se pensate la cosa sia risolvibile,
oppure di piů non č possibile chiedere ad una macchina del genere....
Grazie x l'attenzione
--
Francesco Marchioni
fmarc...@libero.it

Nello specifico non saprei, noi lo usiamo su Sun ;-)
Hai gia' porovato a modificare l'impostazione dello heap della VM? Nel
file jserv.properties, sotto la direttiva
wrapper.bin=/usr/java/bin/java, aggiungi la direttiva
wrapper.bin.parameters=-ms16m -mx64m (per esempio! il valore giusto
dello heap devi provare ad "indagarlo" un po' da solo ;-))
Altrimenti puoi anche fare load balacing su JServ, mettendo una o piu'
istanze di JServ su macchine diverse (Apache e JServ comunicano via
TCP, e Apache e' in grado nativamente di bilanciare il carico su JServ)
Altrimenti... fai come me e muovi la business logic dai servlet verso
un application server (su un altre macchine ;-))! Cio' mi ricorda che
avevo promesso di scrivere un resoconto della mia esperienza in
merito... (quella che ho in modo molto originale battezzato
architettura 4T). Vabbe', oggi salto il pranzo, scrivo e lo posto sul
NG.
Fammi sapere se si muove qualcosa.
Ciao,
    Bruno.

--
Bruno Bossola, a Java Developer
Sent via Deja.com 
http://www.deja.com/
Before you buy.




Grazie x l'attenzione
Di fronte a problemi di carico, ci sono due (tre :) cose da fare, in genere:
 - profiling dettagliato
 - ottimizzazione (come conseguenza del profiling)
 - redesign, se necessario
Le prime due cose sono ovvie - anche se l'ottimizzazione e' comunque un lavoro 
che richiede sforzo, pazienza e.. skill. ;-) La terza un po' meno - dato che il 
design per ottimizzazione segue linee guida diverse da quello usuale. Per 
esempio, puoi dover rinunciare a spingere su modularizzazione, riuso e 
"chiarezza" - ad esempio raggruppando operazioni che sarebbero funzionalmente 
distinguibili per minimizzare lo scambio dati su network o, appunto, l'uso di 
memoria. 
C'e' da dire che con le servlet il design e' in gran parte gia' fatto - e 
inerentemente "pesante". Si puo' tuttavia lavorare su pooling, caching, sharing 
di oggetti, o oggetti façade (che si "riempiono" solo se necessario).
150-160 in contemporanea (cosa intendi con "contemporanea"? Ogni due secondi? 
Ogni cinque? :) sono comunque un bel po' di richieste, ed e' difficile scalare 
una soluzione singola-macchina piu' di tanto. Un problema in quei casi e' che 
il garbage collector puo' non aver fisicamente il tempo di girare - nel qual 
caso puoi provare ad alzargli la priorita' o semplicemente mandare in yeld() 
esplicito tutti i tuoi processi ed invocarlo esplicitamente.
In generale, dovresti fare una stima di carico parametrica - pre-coding - per 
definire con una certa confidenza statistica un limite minimo teorico di 
memoria occupata (che ti dice, *al meglio possibile*, quanta memoria ti serve 
in media per richiesta). Fatta quella, armato dei risultati del profiling, vedi 
quanto "cattiva" e' la tua soluzione rispetto a quella ottimale, e quali sono i 
colli di bottiglia (o le aree divoratrici di memoria) e lavori al tuning. La 
cosa difficile delle soluzioni "web", in effetti, e' solo il problema di 
scalarse su grossi volumi di carico.
Come dice Bruno, l'unica cosa da fare a volte e' disaccoppiare la servlet con 
la logica di servizio. Usando CORBA, per esempio, puoi avere "gratis" il load 
balancing a livello middleware - e' uno dei suoi servizi. Pero' non si scappa: 
ti servono piu' macchine, o piu' processori, o piu' memoria - altrimenti rischi 
di peggiorare la situazione. Oltre certi limiti, non c'e' verso. Puoi anche 
usare framework piu' leggeri ed efficienti di RMI - la Metamata ne ha uno, mi 
pare, e cosi' IBM, ad alphaworks.
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun

 Bruno Bossola, a Java Developer
Io consiglio di evitare a tutti i costi oggetti String e di sostituirli con
StrinBuffer.
Ciao




magari ci trovi un bel viaggetto x il prossimo weekend.
Ehm, avete partenze da Oslo/Gardermoen? :)
-- 
God is Real, unless declared Integer.
ObjectZone - 
http://space.tin.it/computer/csadun/