Newsgroup: it.comp.www.asp
Titolo: DLLHOST: Questione di stile?...

Carissimi,
vorrei cortesemente conoscere la vostra opinione su quanto segue.
Gestisco un sito web molto "trafficato" in tutte le ore del giorno. Ho 
notato che il DLLHOST aumenta costantemente in termini di occupazione di 
memoria. Ho attivato la protezione applicazione alta (isolata) in IIS e 
installato IIS5Recycler.
Pensando a connessioni non chiuse o a recordset lasciati aperti, ho 
verificato il codice asp ma... in tutto il sito non mi pare di aver 
trovato nulla di anormale.
Ora mi chiedo: non è che si tratti semplicementi di... "questioni di 
stile"? ;)
Mi spiego meglio.
Io attualmente gestisco connessioni e recordset, nelle varie pagine asp 
che compongono il sito, in questo modo:
<%
Dim conn
Set conn = Server.CreateObject("ADODB.Connection")
conn.Open "Driver={MySQL}; Server=xxx.xxx.xxx.xxx; Port=3306; 
Database=nomedb; Uid=user; Pwd=password;"
[ ... CODICE HTML DELLA PRIMA PARTE DELLA PAGINA ... ]
Set rs = Server.CreateObject("ADODB.Recordset")
rs.Open "SELECT ID, Titolo FROM Contents WHERE codice='AX25' AND tipo=1 
ORDER BY ID DESC", conn
Do While Not rs.EOF
	[ ... CODICE PER "STAMPARE" SULLA PAGINA I RECORD CHE MI INTERESSANO + 
CODICE HTML ... ]
	rs.MoveNext
Loop
[ ... ALTRO CODICE HTML ... ]
rs.Close
Set rs=Nothing
conn.Close
Set conn=Nothing
%>
Nella pagina asp magari posso aprire parecchi recordset ma essi vengono 
sempre chiusi prima della fine della pagina stessa. Le ultime istruzioni 
sono sempre  conn.Close  e Set conn=Nothing.
Le ultime due e quelle per l'apertura della connessione generalmente le 
metto in un file include in modo da poterle cambiare rapidamente qualora 
cambiassi qualche parametro di connessione.
E' corretto questo modo di operare?
O forse è meglio non aprire direttamente la connessione ma invocare, per 
ciascuna query da eseguire sulla base dati, istruzioni simili a quella 
che segue?:
Set rs = Server.CreateObject("ADODB.Recordset")
rs.CursorLocation = 3
rs.Open 
StrSQL,"Driver={mySQL};Server=xxx.xxx.xxx.xxx;Port=3306;Option=131072;Stmt=;Database=nomedb;Uid=user;Pwd=password;" 
,1,2,1
Tutte queste elucubrazioni per capire il perché del comportamento del 
DLLHOST...
Chi è così gentile da dire la sua in proposito?
Grazie mille in anticipo.
Lorenzo.

 installato IIS5Recycler.
allora dllhost mantiene la cache isapi e ovviamente lo stato delle sessioni 
degli utenti, pertanto se NON usi sessioni disattivale oppure riduci la 
durata della sessione stessa (di default 20 minuti) in iis in questo modo 
risparmi memoria
Per quanto concerne la cache consiglio di lasciarla in quanto hai si un 
maggior consumo di ram ma in cambio le performance sono maggiori, infine 
consiglio spassionato visto che parliamo di iis 5 imposta correttamente le 
performance ovvero se il sito ha come penso più di 100'000 hits quotidiani 
impostale correttamente in iis
Infine ultimo consiglio spassionato, cambia mysql visto che stai ancora 
usando la versione 3 nella versione 4.0.x e aggiungi un po' di ram che non 
guasta mai ed inoltre non costa così tanto :-P
-- 
ITHost (your host company)
Technical Manager
C. Paparelli (MCSE,MCSD,MCDBA)
http://www.ithost.ch
 

 impostale correttamente in iis
ok :)
Grazie!! Ciao.
Lorenzo.

> questo modo risparmi memoria
Sono riuscito a trovare la relativa opzione (comunque l'avevo già 
impostata a 5 minuti).
Grazie, Lorenzo!
P.S. Per quanto riguarda la "questione di stile" che avevo posto 
qualcuno ha da fornirmi un parere? L'uso di un metodo o di un altro per 
la gestione di connessioni e recordset può avere impatto 
sull'occupazione in memoria del DLLHOST?
--

 recordset puň avere impatto sull'occupazione in memoria del DLLHOST?
si certo piů che la gestione dei recordset o delle command il "problema" sta 
nel tuning del database, cosa che per la maggior parte degli sviluppatori č 
totalmente ignorata
Ti lascio un link pensato per Access 2000 
http://support.microsoft.com/?kbid=209126
Ma lo stesso, con le opportune modifiche DEVE venir applicato anche su altri 
db, pertanto usare gli indici, utilizzare stored procedure, usare alias e 
viste, o ovviamente analizzare e valutare ogni singola query, inoltre se un 
db vive e quindi ha e subisce aggiunte, modifiche e cancellazioni di record 
č bene ricontrollare regolarmente le ottimizzazioni e gli indici
