Låt oss analysera detta samtidigt som vi tänker på att SQL har en ORDER BY-klausul:-
do until rs.eof
response.flush
counter = counter + 1
' A LOT of calculations and putting in array...
rs.movenext
loop
Notera Response.Flush , det första jag skulle göra är att bli av med det. Du kommer förmodligen att behöva öka ASP Response Buffering Limit (i IIS-hanteraren). Flush skickar det genererade innehållet så långt till klienten, det väntar på att klienten ska bekräfta mottagandet av alla paket som skickats innan det slutförs. Det är där jag gissar att 90 % av de 5+ minuterna spenderas.
Nu "MYCKET beräkningar". VBScript är inte känt för sin prestanda. Den här koden kan mycket väl ta lite tid. I vissa fall kan vissa beräkningar göras mycket bättre med SQL än i skript, så det är ett alternativ. En annan skulle vara att bygga någon COM-kompilerad komponent för att utföra komplext arbete (även om en del redovisning måste göras för rangering vilket kan utplåna fördelarna). Det kan dock vara oundvikligt att du behöver göra dessa beräkningar i VBScript.
Nu rs.movenext . Denna loop innebär att du håller anslutningen och raduppsättningen öppna i stort sett hela tiden som bearbetningen krävs. Det vill säga medan servrarna skickar bytes över nätverket till klienten och medan VBScript knackar siffror. Ett mycket bättre tillvägagångssätt skulle vara att snabbt suga upp hela raduppsättningen och koppla från DB, då knacka siffror och äntligen dumpa bufferten till klienten.
Överväg att använda en frånkopplad postuppsättning (du anger en statisk markör på klientsidan) eller till och med den enkla GetRows metod för postuppsättningsobjektet som dumpar hela raduppsättningen i en 2-dimensionell array. Detta kommer att innebära att du upprätthåller lås på de olika borden under så kort tid som möjligt.