Analicemos esto teniendo en cuenta que SQL tiene una cláusula ORDER BY:-
do until rs.eof
response.flush
counter = counter + 1
' A LOT of calculations and putting in array...
rs.movenext
loop
Tenga en cuenta la Response.Flush , lo primero que haría sería deshacerme de eso. Probablemente necesitará aumentar el límite de almacenamiento en búfer de respuesta de ASP (en el administrador de IIS). Flush está enviando el contenido generado hasta el momento al cliente, espera a que el cliente acuse recibo de todos los paquetes enviados antes de que se complete. Ahí es donde supongo que se está gastando el 90 % de los más de 5 minutos.
Ahora "MUCHOS cálculos". VBScript no es conocido por su rendimiento. Este código bien puede tomar algún tiempo. En algunos casos, algunos cálculos se pueden hacer mucho mejor con SQL que con un script, por lo que esa es una opción. Otra sería construir algún componente compilado COM para hacer un trabajo complejo (aunque se necesita hacer algo de contabilidad para la clasificación, lo que puede eliminar los beneficios). Sin embargo, puede ser inevitable que necesite hacer estos cálculos en VBScript.
Ahora rs.movenext . Este ciclo significa que mantiene la conexión y el conjunto de filas abiertos durante casi todo el tiempo que se requiere el procesamiento. Es decir, mientras los servidores envían bytes a través de la red al cliente y mientras VBScript procesa números. Un enfoque mucho mejor sería succionar todo el conjunto de filas rápidamente y desconectarse de la base de datos, luego calcular números y finalmente volcar el búfer al cliente.
Considere usar un conjunto de registros desconectado (usted especifica un cursor estático del lado del cliente) o incluso el simple GetRows método del objeto de conjunto de registros que vuelca todo el conjunto de filas en una matriz bidimensional. Esto significará que mantendrá bloqueos en las distintas tablas durante el menor tiempo posible.
