Analysons cela tout en gardant à l'esprit que le SQL a une clause ORDER BY :-
do until rs.eof
response.flush
counter = counter + 1
' A LOT of calculations and putting in array...
rs.movenext
loop
Notez le Response.Flush , la première chose que je ferais serait de m'en débarrasser. Vous devrez probablement augmenter la limite de mise en mémoire tampon des réponses ASP (dans le gestionnaire IIS). Flush envoie le contenu généré jusqu'à présent au client, il attend que le client accuse réception de tous les paquets envoyés avant de se terminer. C'est là que je suppose que 90 % des 5 minutes et plus sont passées.
Maintenant "BEAUCOUP de calculs". VBScript n'est pas connu pour ses performances. Ce code peut prendre un certain temps. Dans certains cas, certains calculs peuvent être effectués beaucoup mieux par SQL que par script, c'est donc une option. Une autre consisterait à créer un composant compilé COM pour effectuer un travail complexe (bien qu'une certaine comptabilité doive être faite pour le rassemblement, ce qui peut anéantir les avantages). Cependant, il peut être inévitable que vous deviez effectuer ces calculs dans VBScript.
Maintenant rs.movenext . Cette boucle signifie que vous maintenez la connexion et l'ensemble de lignes ouverts pendant à peu près tout le temps nécessaire au traitement. C'est-à-dire pendant que les serveurs envoient des octets sur le réseau au client et pendant que VBScript traite les chiffres. Une bien meilleure approche serait d'aspirer rapidement tout l'ensemble de lignes et de se déconnecter de la base de données, puis calculez les chiffres et enfin vider le tampon sur le client.
Envisagez d'utiliser un jeu d'enregistrements déconnecté (vous spécifiez un curseur statique côté client) ou même le simple GetRows méthode de l'objet recordset qui vide l'ensemble de lignes entier dans un tableau à 2 dimensions. Cela signifie que vous maintenez les verrous sur les différentes tables pendant le moins de temps possible.
