Lad os analysere dette, mens vi også husker på, at 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
Bemærk Response.Flush , den første ting jeg ville gøre er at slippe af med det. Du bliver sandsynligvis nødt til at øge ASP Response Buffer Limit (i IIS manager). Flush sender det genererede indhold indtil videre til klienten, den venter på, at klienten anerkender modtagelsen af alle de sendte pakker, før den er færdig. Det er der, jeg vil gætte på, at 90 % af de 5+ minutter bliver brugt.
Nu "MANGE beregninger". VBScript er ikke kendt for sin ydeevne. Denne kode kan godt tage lidt tid. I nogle tilfælde kan nogle beregninger udføres meget bedre med SQL end i script, så det er en mulighed. En anden ville være at bygge en eller anden COM-kompileret komponent til at udføre komplekst arbejde (selvom der skal laves noget regnskab til rangering, hvilket kan udslette fordele). Det kan dog være uundgåeligt, at du skal udføre disse beregninger i VBScript.
Nu rs.movenext . Denne løkke betyder, at du holder forbindelsen og rækkesættet åbent stort set hele tiden, behandlingen er påkrævet. Det er mens serverne sender bytes over netværket til klienten, og mens VBScript knuser tal. En meget bedre tilgang ville være at suge hele rækkesættet hurtigt op og afbryde forbindelsen til databasen, så knasende tal og endelig dump bufferen til klienten.
Overvej at bruge et frakoblet recordset (du angiver en statisk markør på klientsiden) eller endda den simple GetRows metode for postsætobjektet, der dumper hele rækkesættet i et 2-dimensionelt array. Det vil betyde, at du vedligeholder låse på de forskellige borde i mindst mulig tid.