Vamos analisar isso, tendo em mente que o SQL tem uma cláusula ORDER BY:-
do until rs.eof
response.flush
counter = counter + 1
' A LOT of calculations and putting in array...
rs.movenext
loop
Observe o
Response.Flush , a primeira coisa que eu faria é me livrar disso. Você provavelmente precisará aumentar o limite de buffer de resposta do ASP (no gerenciador do IIS). Flush está enviando o conteúdo gerado até o momento para o cliente, ele espera que o cliente confirme o recebimento de todos os pacotes enviados antes de concluir. É aí que eu acho que 90% dos mais de 5 minutos estão sendo gastos. Agora "MUITO cálculos". VBScript não é conhecido por seu desempenho. Este código pode levar algum tempo. Em alguns casos, alguns cálculos podem ser feitos muito melhor por SQL do que por script, então essa é uma opção. Outra seria construir algum componente compilado COM para fazer um trabalho complexo (embora algumas contas precisem ser feitas para marshalling, o que pode acabar com os benefícios). No entanto, pode ser inevitável que você precise fazer esses cálculos em VBScript.
Agora
rs.movenext . Esse loop significa que você mantém a conexão e o conjunto de linhas abertos praticamente o tempo todo em que o processamento é necessário. Isso é enquanto os servidores estão enviando bytes pela rede para o cliente e enquanto o VBScript está processando números. Uma abordagem muito melhor seria sugar todo o conjunto de linhas rapidamente e desconectar do banco de dados, então processar números e finalmente despeje o buffer para o cliente. Considere usar um conjunto de registros desconectado (você especifica um cursor estático do lado do cliente) ou até mesmo o simples
GetRows método do objeto de conjunto de registros que despeja todo o conjunto de linhas em uma matriz bidimensional. Isso significa que você mantém bloqueios nas várias tabelas pelo menor tempo possível. 
