Przeanalizujmy to, jednocześnie pamiętając, że SQL ma klauzulę ORDER BY:-
do until rs.eof
response.flush
counter = counter + 1
' A LOT of calculations and putting in array...
rs.movenext
loop
Zwróć uwagę na Response.Flush , pierwszą rzeczą, którą bym zrobił, to się tego pozbyć. Prawdopodobnie będziesz musiał zwiększyć Limit buforowania odpowiedzi ASP (w menedżerze IIS). Flush do tej pory wysyła wygenerowaną zawartość do klienta, czeka na potwierdzenie odbioru wszystkich wysłanych pakietów przed zakończeniem. Zgaduję, że właśnie tam spędza się 90% z 5+ minut.
Teraz "DUŻO obliczeń". VBScript nie jest znany ze swojej wydajności. Ten kod może zająć trochę czasu. W niektórych przypadkach niektóre obliczenia można wykonać znacznie lepiej w SQL niż w skrypcie, więc jest to jedna z opcji. Innym byłoby zbudowanie jakiegoś komponentu skompilowanego w COM, aby wykonać złożoną pracę (chociaż konieczne jest wykonanie niektórych księgowości dla marshallingu, co może zniweczyć korzyści). Jednak może być nieuniknione, że będziesz musiał wykonywać te obliczenia w VBScript.
Teraz rs.movenext . Ta pętla oznacza, że utrzymujesz otwarte połączenie i zestaw wierszy przez prawie cały czas, gdy wymagane jest przetwarzanie. Dzieje się tak, gdy serwery wysyłają bajty przez sieć do klienta, a VBScript przetwarza liczby. O wiele lepszym rozwiązaniem byłoby szybkie wyssanie całego zestawu wierszy i odłączenie od bazy danych, następnie crunch liczb i nareszcie zrzuć bufor do klienta.
Rozważ użycie odłączonego zestawu rekordów (określasz statyczny kursor po stronie klienta) lub nawet prostego GetRows metoda obiektu zestawu rekordów, która zrzuca cały zestaw wierszy do tablicy 2-wymiarowej. Oznacza to, że będziesz utrzymywać blokady na różnych stołach przez możliwie najkrótszy czas.
