I forum Ricerca FAQ
Fai una domanda
Ultimo messaggio
pdb
pdb
il 25 novembre 2002 alle 16:02
839 messaggi dal 13 febbraio 2001
Ho provato a monitorare il tempo di esecuzione di ogni pagina per cercare di ottimizzarne il codice.
Sono rimasto inorridito nello scoprire la lentezza di ADO nell'apertura dei recordset.
Ad esempio per aprire una tabella di 20 campi e 50 records lo script richiede circa 0,12 sec. Per aprire la stessa ma con 70 campi, il tempo passa a 1,3 secondi, indipendentemente dal database usato (access o qualche sql server non fa differenza).
Significa che viene richiesto molto piu' tempo solo per generare il recordset che per svolgere tutte le restanti operazioni (esecuzione query, scorrimento del recordset, presentazione dei dati, ecc).
A dimostrazione che fare SELECT * è molto peggio che specificare i singoli campi con SELECT campo1, campo2, ecc

Il tempo usato per calcolare il tempo di esecuzione dello script è questo: 
<SCRIPT LANGUAGE="Jscript" RUNAT="server">
  // Jscript server-side code to get more accurate script execution time.
   var GLOBAL_JSNOW;
   GLOBAL_JSNOW = GetStartTime()

function GetStartTime() {
   var d;
   d = new Date();
   return(d.getTime())
}

function GetTime() {
   var d, n;
   d = new Date();
   n=(d.getTime() - GLOBAL_JSNOW) / 1000
   return(n.toPrecision(2))
 }
</SCRIPT>

messo a inizio pagina e richiamato alla fine con 
<%= "[Script execution time: " & GetTime() & " secs.] " %>

Conoscete qualche metodo piu' semplice?
Modificato da pdb il 25 novembre 2002 16.02 -
RispondiQuoting
pabloj
pabloj
il 26 novembre 2002 alle 09:57
823 messaggi dal 05 agosto 2002
Mi pare che ADO faccia tutto in RAM, tu quanta ne hai?
Stick to your guns.
Formazione su MySQL o Firebird? Contattami!
RispondiQuoting
pdb
pdb
il 26 novembre 2002 alle 10:41
839 messaggi dal 13 febbraio 2001
Mezzo giga basta?
No, a parte scherzi penso proprio che sia il meccanismo di creazione degli oggetti campo e delle loro proprietà sia lento, specie quando i campi sono tanti.
Avevo sperimentato una volta con una tabella di circa 250 campi e il tempo impiegato era 5 secondi.
A questo punto, i tempi mi sembrano esagerati, per un uso realistico.
RispondiQuoting
Andrea Palmatè
Andrea Palmatè
il 26 novembre 2002 alle 10:48
1.983 messaggi dal 28 febbraio 2001
Contributi
www.amigasoft.net
C'è qualcuno che ti dirà usa ADO.NET.. io ti posso dire.. usa dei drivers ottimizzati esterni.. magari dovrai usare sempre ADO per creare gli oggetti, ma ci guadagnerai nel fetch dei record. Soprattutto se usi Oracle o SQL Server.

P.S.
C'è sempre Java..
--
Andrea Palmatè
RispondiQuoting
pdb
pdb
il 26 novembre 2002 alle 10:58
839 messaggi dal 13 febbraio 2001
I problema non è la navigazione nel recordset, ma il tempo impiegato per la sua apertura, che purtroppo in ASP è tipicamente effettuata ad ogni esecuzione di ogni pagina.

E' un problema di ADO, ho provato con sql server e il tempo di apertura è esattamente lo stesso. Si può usare ADO.NET su ASP 2.0 su NT? Mi pare di no.

Cosa intendi per "drivers ottimizzati esterni"?
RispondiQuoting
Andrea Palmatè
Andrea Palmatè
il 26 novembre 2002 alle 11:48
1.983 messaggi dal 28 febbraio 2001
Contributi
www.amigasoft.net
No, ADO.NET sotto NT non funge. Per drivers esterni, intendo divers di terze parti e al posto di ADO usare JAVA
--
Andrea Palmatè
RispondiQuoting
alterx
alterx
il 26 novembre 2002 alle 12:49
106 messaggi dal 11 novembre 2002
Allora prova a fare queste due operazioni:
prima di tutto imposta la proprieta del recordset Options=adCmdText, che specifica di utilizzare come sorgente una stringa SQL....
Secondo, la più importante controlla se nei filtri della tua query ci sono campi dichiarati nel DB come indici; molte volte non lo si fa e si sbaglia!

Terzo, non puoi affidarti nel tempo che ti viene restituito, perchè dipende dal tanti fattori: window è multitasking e quindi può agevolare altri processi prima del tuo, secondo la risposta non dipende da ADO ma dal server DB che risponde e poi ci sono i motivi su indicati.

ADO è leggerissimo occupa in memoria solo 300Kb o qualcosa di più quindi non è problema di RAM
RispondiQuoting
pdb
pdb
il 26 novembre 2002 alle 13:39
839 messaggi dal 13 febbraio 2001
Allora... provate a fare una tabella vuota con 255 campi e guardate quanto tempo ci mette ad aprirla. Solo ad aprirla, intendo. Non dico il tempo rilevato, ma mi sembra una cosa oscena.
E date anche una bella occhiata al carico sulla CPU!

Poi riprovate con una tabella di una decina di campi.

Alla fine, usando la tabella grande guardate che diffenza c'e' usando l'opzione adCmdTable e adCmdTableDirect !!!!!

Questo è il banale script che ho usato:
<SCRIPT LANGUAGE="Jscript" RUNAT="server">
  // Jscript server-side code to get more accurate script execution time.
   var GLOBAL_JSNOW;
   GLOBAL_JSNOW = GetStartTime()

function GetStartTime() {
   var d;
   d = new Date();
   return(d.getTime())
}

function GetTime() {
   var d, n;
   d = new Date();
   n=(d.getTime() - GLOBAL_JSNOW) / 1000
   return(n.toPrecision(2))
 }
</SCRIPT>
<%
Dim objCnn
Dim objRst
Set objCnn = Server.CreateObject("Adodb.Connection")
Set objRst = Server.CreateObject("Adodb.Recordset")
objCnn.Open "provider=Microsoft.Jet.OLEDB.4.0;data source=D:\InetPub\wwwroot\_private\Databases\db1.mdb;"
objRst.Open "Table1", objCnn, , , adCmdTable
Response.Write GetTime()
objRst.Close
Set objRst = Nothing
objCnn.Close
Set objCnn = Nothing
%>
Modificato da pdb il 26 novembre 2002 13.56 -
RispondiQuoting

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.