Нека анализираме това, като същевременно имаме предвид, че SQL има клауза ORDER BY:-
do until rs.eof
response.flush
counter = counter + 1
' A LOT of calculations and putting in array...
rs.movenext
loop
Обърнете внимание на Response.Flush , първото нещо, което бих направил, е да се отърва от това. Вероятно ще трябва да увеличите лимита за буфериране на ASP отговор (в IIS мениджъра). Flush изпраща генерираното досега съдържание на клиента, изчаква клиентът да потвърди получаването на всички изпратени пакети, преди да завърши. Това е мястото, където предполагам, че са изразходвани 90% от 5+ минути.
Сега "МНОГО изчисления". VBScript не е известен със своята производителност. Този код може да отнеме известно време. В някои случаи някои изчисления могат да бъдат направени много по-добре от SQL, отколкото в скрипт, така че това е една от опциите. Друго би било да се изгради някакъв COM компилиран компонент за извършване на сложна работа (въпреки че трябва да се направи известно счетоводство за сортиране, което може да унищожи ползите). Въпреки това може да е неизбежно да трябва да направите тези изчисления във VBScript.
Сега rs.movenext . Този цикъл означава, че държите връзката и набора от редове отворени почти през цялото време, когато се изисква обработката. Това е докато сървърите изпращат байтове по мрежата към клиента и докато VBScript разбива числа. Много по-добър подход би бил да изсмучете бързо целия набор от редове и да прекъснете връзката с DB, след което кратки числа и накрая изхвърлете буфера на клиента.
Помислете за използване на несвързан набор от записи (посочвате статичен курсор от страна на клиента) или дори простия GetRows метод на обекта набор от записи, който изхвърля целия набор от редове в двуизмерен масив. Това ще означава, че поддържате ключалки на различните маси за възможно най-кратко време.
