Laten we dit analyseren terwijl we er ook rekening mee houden dat de SQL een ORDER BY-clausule heeft:-
do until rs.eof
response.flush
counter = counter + 1
' A LOT of calculations and putting in array...
rs.movenext
loop
Let op de Response.Flush , het eerste wat ik zou doen, is dat wegwerken. U zult waarschijnlijk de ASP Response Buffering Limit (in IIS Manager) moeten verhogen. Flush verzendt de gegenereerde inhoud tot nu toe naar de client, het wacht tot de client de ontvangst van alle verzonden pakketten bevestigt voordat het is voltooid. Dat is waar ik denk dat 90% van de 5+ minuten wordt besteed.
Nu "VEEL berekeningen". VBScript staat niet bekend om zijn prestaties. Deze code kan enige tijd duren. In sommige gevallen kunnen sommige berekeningen veel beter met SQL worden gedaan dan in script, dus dat is een optie. Een andere zou zijn om een door COM gecompileerde component te bouwen om complex werk te doen (hoewel er enige boekhouding moet worden gemaakt voor marshalling, wat voordelen kan tenietdoen). Het kan echter onvermijdelijk zijn dat u deze berekeningen in VBScript moet uitvoeren.
Nu rs.movenext . Deze lus betekent dat u de verbinding en rijenset vrijwel de hele tijd openhoudt voor verwerking. Dat is terwijl de servers bytes over het netwerk naar de client sturen en terwijl VBScript cijfers aan het kraken is. Een veel betere aanpak zou zijn om alle rijen snel op te zuigen en los te koppelen van de DB, dan crunch-nummers en eindelijk dump de buffer naar de client.
Overweeg het gebruik van een niet-verbonden recordset (u specificeert een statische cursor aan de clientzijde) of zelfs de eenvoudige GetRows methode van het recordset-object dat de hele rijenset in een tweedimensionale array dumpt. Dit betekent dat u zo min mogelijk sloten op de verschillende tafels onderhoudt.