Newsgroup: it.comp.www.asp
Titolo: Connessioni (TEST)

Non avendo ricevuto risposte ai mie post sulla possibilità di mettere nel
pooling le connessioni ho fatto un piccolo test:
Ho creato due pagine identiche che effettuano una Select su un db, nalla
pagina A chiudo recordset e connessione e li elimino dalla memoria, nella
pagina B non faccio niente di tutto questo.
Ecco i risultati ottenuti tramite la stress utility di microsoft (ho fatto
brevi test di 3 minuti)
20 connessioni simultanee
Pagina     Code      Description   Count
==============================
  A           200       OK                   806
  A           403       Forbidden          11
  B           200       OK                  757
  B           403       Forbidden           6
Pagina   Hits      TTFB Avg  TTLB Avg
============================
   A       817       260.30         326.77
   B       763       180.84          247.31
40 connessioni simultanee
Pagina    Code      Description         Count
=============================
   A         200        OK                   1407
   A         403       Forbidden              69
   A         NA        HTTP result code not given    2
   B         200       OK                     1537
   B         403       Forbidden             55
   B         NA        HTTP result code not given    4
Pagina   Hits      TTFB Avg  TTLB Avg
============================
   A       1478       344.16       403.86
   B        1596      275.72       332.39
Quindi a giudicare da questi risultati le pagine dove non chiudo le
connessioni sembrerebbero funzionare meglio. Inoltre anche non chiudendo le
connessioni il driver ODBC di access non ha dato errori per troppi utenti
collegati al DB.
In conclusione sembrerebbe che COM+ inserisce nel pooling le connessioni, di
conseguenza chiuderle ogni volta diventa uno spreco e non un una buona
norma.
Aspetto vostri commenti
Ciao Marco.


Moderatore di it.comp.www.asp
Sito di supporto: 
http://www.aspitalia.com/newsgroup/
La più grande community italiana di sviluppatori!

 connessi, e comunque Access non č certo l'ideale per test di questo tipo.
avevo utilizzato volutamente Acces per capire come si comporta, mi aspettavo
che senza chiudere le connessioni queste rimanessero aperte (una per ogni
accesso) fino al timeout di sessione, provocando cosě degli errori di
accesso al database.
Ciao Marco

Grazie per i test.
Tieni conto:
1. che il "pool delle connessioni" non lo gestisci te, chiudendo ed aprendo
connessione e recordset, bensì lo gestisce il sistema. Guarda nel pannello
di controllo ODBC e troverai la scheda "Pool di Connessioni". Se fai doppio
click sulle descrizioni dei vari driver ODBC vedrai se sono attivate oppure
no, e quanto è il timeout.
Puoi divertirti a fare esperimenti attivando e disattivando il pool, oppure
ad impostare timeout differenti.
2. Sarebbe da controllare durante e alla fine dei test, se esistono
differenze nella memoria allocata. Se sì, potrebbe essere sintomo di qualche
connessione non chiusa perfettamente. Ed alla lunga (vedi magari qualche
settimana o mese) il sistema potrebbe avere qualche problema.
3. Potresti vedere gli effetti del pooling non solo in lettura, ma in
scrittura, quando cioè il sistema necessità di aggiornare le tabelle.
Chiudendo esplicitamente una connessione appena non serve più oppure
aspettando che ASP ci pensi automaticamente al termine dello script. Questa
è una situazione abbastanza frequente nel mondo reale.

 è una situazione abbastanza frequente nel mondo reale.
aggiungo: per la scrittura il pooling non serve a niente, in molti casi. il
pooling infatti mantiene attiva una conessione se e solo se la stringa di
conessione è identica.
penso a SQL server, ad esempio, dove ci possono essere, allo stesso db,
diversi tipi di utenti (con relative password) che accedono alle stesse
identiche cose, ma con userid e password diverse. in questo caso il pooling
non viene mantenuto (sono in effetti due richieste diverse).
un'altra limitazione è che allochi, come ha già detto Paolo, più memoria di
quanto sia necessaria e con Access questo non è bello. se poi considero che
Access non ha un supporto ottimale per la scrittura (solo un utente può
accedere ad un db in scrittura in un certo istante) capirai perchè è prassi
comune chiudere e liberare risorse il prima possibile.


 comune chiudere e liberare risorse il prima possibile.
Sto ancora leggendo (tra un lavoro e l'altro) un bel po di articoli che ho
trovato in giro.
Mi sconcerta un po che più leggo e più mi sento confuso, comunque la cosa
che veramente non capisco è cosa accade alla connessione se non la chiudo.
A livello di logica è ovvio che bisogna chiuderla per tutte le ragioni che
mi avete spiegato. Ma perchè se non la chiduo non ho errori di accesso al
database. Se ci fossero più di dieci connessioni aperte contemporaneamente
all'undicesima dovrei avere degli errori, perchè non mi accade?
Ciao Marco.

 comune chiudere e liberare risorse il prima possibile.
purtroppo l'ho notato anch'io facendo dei test piuttosto rozzi, però
efficaci.
Come faccio ad evitare l'errore sulla scrittura contemporanea su un db
access (oltre che cambiando DB!!!) ?
Esiste insomma un modo per dire : se il db è occupato > aspetta un attimo ?
Anche perchè devo riavviare iis quando mi da quell'errore!!!!
ciao
Simone

 all'undicesima dovrei avere degli errori, perchè non mi accade?
perchè in realtà Access supporta 255 connessioni contemporanee, ma se
"configurato" bene (accesso via OLE-db, cursor e lock type appropriati) ne
regge anche una sessantina... tu hai fatto test fino a 40 (se non ricordo
male) e quindi non hai avuto problemi :-)
cmq, lo svantaggio maggiore di avere una connessione aperta che tot k di
memoria rimangono lì allocati anche se nessuno li userà mai.


 Esiste insomma un modo per dire : se il db è occupato > aspetta un attimo
?
on error resume next
' scrivo qui
if err<>0 then
    Response.write err.Description
end if
ora non ricordo il numero di errore che restituisce, ma potresti
personalizzare questa routine in modo che dica che il db è già bloccato.
