Discussion :

[Immobilis]

Ce message vient de reponses postées dans la discussion : http://www.developpez.net/forums/d50...ommentaires-o/


Salut,

Merci pour ces codes.
Est-ce que tu peux mettre le code de la classe cDB?

Par contre, en ASP3, par experience, ce n'est pas forcement très performant de créer une connexion pour chaque requete. Il vaut mieux en créer une par page asp et utiliser uniquemment celle là en la transmettant aux classes, fonctions et procédures par l'intermédiaire d'une propriété ou un paramètre.

Pour ce qui est des de libérer la connexion et utiliser le recordset obtenu, c'est tout à fait possible en utlisant un curseur client (tout ceux qui renvoi un recordcount différent de -1). Ce recordeset est "détaché" et lisible plusieurs fois (on peut revenir au début).

A+

[roro06]

Bonjour

Je suis avec intérêt cette rubrique depuis le début, même si je n'y contribue pas (pas encore).

ce n'est pas forcement très performant de créer une connexion pour chaque requete

Absolument, je dirai même que c'est à proscrire.

quelques remarques :

Dans le cas de la fonction a_data, tu boucles 2 fois sur le recordset, la première fois pour compter le nombre d'enregistrements, la deuxième fois pour créer autant d'objets dictionnary que d'enregistrements.

Je pense que cette méthode risque d'aller à contre-sens de l'objectif initial, à savoir de "fermer la connexion dés que possible", particulièrement sur des jeux d'enregistrements un peu "gros" (je rappelle : 1 dictionnary par enregistrement ! imagine si tu as 50 000 enregistrements, et trente clients en même temps).
Je pense qu'une simple boucle :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
while not rs.eof
response.write elt("Nom") & "<br>"
response.write elt("Prenom") & "<br>"
response.write elt("Adresse") & "<br>"
rs.movenext
wend

A plus de chances d'être plus performante en terme de rapidité et de ressources machine.

Attention également :

set dico = createObject("Scripting.Dictionary")

Utilise plutôt, en ASP3 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

set dico = server.createObject("Scripting.Dictionary")

[Immobilis]

ce n'est pas forcement très performant de créer une connexion pour chaque requete

Absolument, je dirai même que c'est à proscrire.

Pourquoi?
Oui et non, en cas de doute la bonne pratique reste "créer tard, detruire tôt". En ASP3, les connections sont très mal gérées. Dans le cas d'un site à fort trafic, on peut rapidement les faire grimper saturer le serveur de données. Il vaut donc mieux en créer une au début du script la transmettre et la fermer en fin de script.

A+

[StephM_asp]

Salut tous les deux et merci de vos interventions.

Je répond par étape et vais essayer de ne rien oublier.

Alors le code de la classe c'est le tiens en fait, je ne fais qu'y passer la chaine de connexion que j'ai au préalable placé dans un fichier ini.asp, en constante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
 
Class cDB
 
        ' Les variable privées sont inaccessibles depuis l'exterieur
        ' nous les consulterons par l'intermediaire de leurs propriétés nommées "accessers".
        ' Les accessers sont comme des fonctions.
        Private m_Provider ' variable privée de la chaine de connection
        Private oConn ' objet privée de connection
        Private oCmd ' objet privé de command
 
        ' Ce que va faire la classe au moment de son instanciation
        ' 1 - Créer une connection ADO
        ' 2 - Créer une command ADO
        Private Sub Class_Initialize
                Set oConn = Server.CreateObject("ADODB.Connection")
                Set oCmd = Server.CreateObject("ADODB.Command")
                m_Provider = CONN_STRING
				' Au moment où nous allons assigner une valeur à la chaine de connection, nous allons l'ouvrir.
                oConn.ConnectionString = m_Provider
                oConn.Open()
                ' Nous lions la command à l'objet connection
                oCmd.ActiveConnection = oConn
        End Sub
 
        ' Ce que va faire la classe au moment de sa destruction
        ' 1 - detruire l'objet command
        ' 2 - fermer la connection si elle est encore ouverte
        ' 3 - détruire l'objet connection
        Private Sub Class_Terminate
				Set oCmd = Nothing
                If oConn.State = 1 then oConn.Close()
				Set oConn = Nothing
        End Sub
 
        ' Cette propriété execute la requete SQL et renvoi le recordset correspondant
        Public Function SQL(sSQL)
            oCmd.CommandText = sSQL
                Set SQL = oCmd.Execute()
        End Function
End Class

En suite, tu préfères créer une connexion au début de la page et la fermer... Je n'ai pas bien compris quand d'ailleurs, je suppose en fin de page ?

Si j'ai bien compris ton point de vue, je ne suis pas d'accord pour des questions de surcharge sur la base justement.
C'est à dire que si tu as trop de personnes connectées en même temps sur ton site, tu as de fortes chances d'obtenir ce maudit message : "trop de connexions ouvertes en même temps".

Je suis cependant d'accord avec le fait qu'ouvrir et fermer les connexions à chaque fonction alourdi le traitement. Mais, de ce que j'ai pu en constater de visu, il doit s'agir de quelques millisecondes puisque je ne l'ai pas "ressenti".

Enfin, si j'ai bien compris ce que tu me dit, on peut libérer la mémoire d'un RS et par la suite le travailler ? o_O
Si c'est bien ça alors je prendrais le temps de "comprendre" cette histoire de curseur à laquelle tu fais référence...
J'ai regardé rapidement la page que tu donnes en lien et elle mérite plus ample attention Mais ça m'intéressera alors beaucoup.

En suite Roro, hum... Je ne comprends pas vraiment en fait.
J'utilise le bon vieux i++ pour ne pas utiliser le .count qui non seulement est dévoreur de temps (constaté de visu) mais en plus n'est pas compatible avec toutes les versions d'Access.
Ce i++ n'est fait qu'une seule fois par fonction, pas à chaque boucle hein...
Certes ça alourdi un peu le code et ce n'est pas très... propre mais ça reste très efficace, ce que je recherche.
En soit, ça n'a aucun impacte sur le fait de fermer ou non ma connexion.

En suite tu dis :
(je rappelle : 1 dictionnary par enregistrement ! imagine si tu as 50 000 enregistrements, et trente clients en même temps)

Oui, ce que tu dis sous entend que le fait de créer puis de fermer un dico prend beaucoup de temps ?
Franchement j'ai un sérieux doute, je sais pas...
Bon, je vais regarder ça aujourd'hui, je vais créer une table avec 400.000 enregistrements et tester les deux solutions, j'en aurais le coeur net.

Enfin, je ne souhaite pas utiliser directement les RS dans les pages principales comme tu le suggères pour cette fameuse raison de trop plein de connexion simultanées sur le serveur, erreur bloquante !
Donc c'est mon objectif n°1, il est inadmissible pour mes clients de supporter ce genre de chose, je les comprends tout a fait
A moi de ménager la chèvre et le choux et de trouver une solution même si elle ralentie un peu l'usager, je préfères, tu le comprendras, une appli un peu plus lente qu'une appli qui ne marche pas du tout...

Encore merci pour vos deux interventions, j'apprécie grandement d'échanger avec vous.

[StephM_asp]

Ah, j'oubliais, remplacer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
set dico = createObject("Scripting.Dictionary")

par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
set dico = server.createObject("Scripting.Dictionary")

Merci, c'est noté, j'ai fait les modifs nécessaires.

[StephM_asp]

Bien !

Donc, j'ai fait une table "Temp" dans laquelle j'ai placé 400.000 enregistrements.
Puis, j'ai retourné le résultat d'un SELECT * avec les deux méthodes.

Méthode 1 => création et destruction d'un dico pour chaque enreg, bilan après deux minutes environ, le script plante :

Erreur de compilation Microsoft VBScript error '800a03e9'
Mémoire insuffisante
/iisHelp/common/500-100.asp, line 0
Objet Server error 'ASP 0177 : 80004002'
Échec de Server.CreateObject
/projet/lib/fct_array.asp, line 25
Cette interface n'est pas prise en charge

La ligne 25 correspond à la création du dico.
Peut-être serait-il bon de placer un petit response.flush ? Je vais tester.

Donc, hors mis le plantage que je peux peut-être corriger, je ne connais pas encore le temps d'exécution de la requête.

Méthode 2 => création d'un RS, je boucle directement dessus et je response.write de la page mère.

Le script ne plante pas, durée de l'opération : un peu plus de 6 minutes...
conclusion : 6 minutes durant lesquelles la connexion reste ouverte.

Je vais essayer de libérer le buffer plus souvent pour la 1ère méthode.
D'autre part je vais regarder de plus près cette histoire de "curseur client" dont tu m'as parlé.

Quoi qu'il en soit, je suis en train de mélanger deux problèmes et je ne devrais dans un 1er temps.
1 - beaucoup de personnes qui ouvrent et ferment des connexions = "Trop de conn ouvertes en même temps". Pour ça ma solution semble correcte (si pas trop d'enregistrements travaillés à la fois par un même script (mais j'aime pas du tout ce plantage, quoi qu'il en soit, je dois le régler).
2 - un grand nombre d'enregistrements à traiter au plus vite.

Évidemment si au final je peux n'avoir qu'une seule et même solution, ce sera idéal et c'est dans cette direction que je souhaite aller in fine.

++

[StephM_asp]

Bon, je viens de faire un nouveau test vraiment intéressant.
Au lieu d'afficher l'ensemble des résultats, je les affiche par tranche de 10K, bilan des courses l'exécution prend environ 1 seconde avec le RS et encore plus de 20 secondes avec ma fonction a_data.
Étonnant comme "response.write" rallonge les traitements. Remarquez je me souviens qu'en "C" la fonction "print" était énorme !!

Roro tu avais raison, cette méthode n'est vraiment pas recommandée (création puis destruction du dico pour chaque enreg) lorsqu'on a de nombreux enreg à traiter.
En revanche elle permet toujours de fermer la connexion tout en continuant à traiter les infos trouvées (puisque stokées dans un array, donc indépendant du RS initial).

Je viens de regarder d'un peu plus près la configuration de la connexion : type de curseurs et de verrous.
Alors je ne pense pas que ça puisse m'aider à fermer la connexion tout en continuant à travailler sur mon RS (ou alors j'ai loupé quelque chose).
A moins que le verrou "adLockReadOnly" et un curseur "Static" permettent justement ça ?

++

[Immobilis]

Beaucoup de réponses à donner...

1. Tu ferais mieux d'utiliser la classe telle quelle. Une classe est une capsule dans laquelle on ne devrait rentrer que par des propriétés. L'utlisation de "CONN_STRING" (constante globale?) est une mauvaise habitude à ne pas prendre. Garde la propriété "Provider". Ainsi, tu pourras changer ta chaine de connexion (de base de données) facilement dans une même page. Là ta classe est figée.
2. Un recordset dérive d'un tableau puisqu'on peut accéder aux enregistrements par leur index => inutile de créer un dictionnaire à partir d'un recordset, c'est une perte de temps et tu consommes de la mémoire en créant une copie d'un objet qui existe déjà.
3. Du coup, comment laisser une connexion ouverte le moins longtemps possible? Si ton recordset doit être lu plusieurs fois, il faut utiliser un curseur client. Si il n'a besoin d'être lu qu'une fois utilise un curseur serveur. Le curseur serveur est le plus rapide (même en .Net)! Mais tu n'es pas obligé de me croire. Si tes données mettent trop de temps à remonter c'est peut-être que ta requete est mal formulée. Il est rarement nécessaire de remonter 400000 enregistrements sauf pour des tests. Ouvre la connexion recupère tes données puis ferme la connexion. Si ta requête met du temps parce qu'elle est complexe et que tu ne peut pas la formuler autrement et bien tu ne peux pas faire autrement que de laisser la connexion ouverte pendant que la base traite la requete.
4. Faut-il utiliser une ou plusieurs connection par page? A défaut je dirai le moins possible.

   Si j'ai bien compris ton point de vue, je ne suis pas d'accord pour des questions de surcharge sur la base justement.

5. C'est à dire que si tu as trop de personnes connectées en même temps sur ton site, tu as de fortes chances d'obtenir ce maudit message : "trop de connexions ouvertes en même temps".

[StephM_asp]

Re

...
Auparavant, nous utilisions la méthode que tu cites pour récupérer nos données (une connexion par requete). Avec cette méthode, nous avons totalement saturé les 3800 connections (les ports) autorisées par défaut dans SQL Server. Ce phénomène se produit parce que SQL Server a un temps de latence (environ 90s) avant de libérer la connexion ouverte (le port) par un utilisateur. Depuis, nous essayons de limiter au maximum les connections individuelles. Il vaut mieux laisser une connexion ouverte pendant 3+90 secondes que 100 pendant 2+90 secondes.

Donc tu fermes ta connexion à la fin de chaque page ?
Tu ouvres lorsque tu en as besoin puis tu fermes en fin de page ?

Le flush n'est là que pour faire plaisir à l'internaute, mais cela consomme du temps à IIS. Je pense qui vaut mieux "bufferiser" et envoyer la réponse en une seule fois.

C'est un autre débat.
Le flush peut s'avérer très utile lorsque par exemple tu génères un fichier issu de ta base et que ce traitement prend trop de temps. Tu prendras alors un time out.
Faire un flush de temps en temps est, dans ce cas là, non seule invisible pour le client mais en plus permet d'éviter le time out. Donc très utile.

Je pensais que le plantage pouvait venir de là, ce n'était pas le cas.

++

[Immobilis]

Salut,

Donc tu fermes ta connexion à la fin de chaque page ?
Tu ouvres lorsque tu en as besoin puis tu fermes en fin de page ?

Autant que possible oui, tant que je sais que j'ai des données à récuper. Bien entendu, ce n'est pas utile de récupérer juste un enregistrement et laisser une connexion ouverte pendant 2 minutes pour faire 36000 calculs qui ne mobilisent que IIS et pas la base de données.

Tu prendras alors un time out.

Même en augmentant Server.ScriptTimeout?

Je pensais que le plantage pouvait venir de là, ce n'était pas le cas.

Quel plantage?

A+

[StephM_asp]

Hello,

Autant que possible oui, tant que je sais que j'ai des données à récuper. Bien entendu, ce n'est pas utile de récupérer juste un enregistrement et laisser une connexion ouverte pendant 2 minutes pour faire 36000 calculs qui ne mobilisent que IIS et pas la base de données.

Oui, à ce moment là autant la fermer directement à la fin de la fonction.
Je vais essayer de les gérer comme ça à l'avenir, c'est vrai que je ne savais pas que SQL server gardait les connexions ouvertes 90s après que l'on en ait demandé la fermeture... Et bien sûr, je suppose qu'il n'y a pas moyen de limiter cette rétention ?

Même en augmentant Server.ScriptTimeout?

C'est comme tout, tout dépend des circonstances. Le cas dont je te parle était une extraction de 14.000 lignes... Le tout sur un serveur mutualisé ou presque 80 sites cohabitaient, impossible pour moi d'augmenter de trop le ScriptTimeout sans risquer d'autres désagréments...
Le response.flush m'a, ici, bien aidé.

Quel plantage?

Celui dont je parle plus haut, qui a eut lieu au bout de 380.000 enregistrements extraits. Le flush n'a eut aucun effet. Et je n'en connais toujours pas la cause d'ailleurs.

Mais quoi qu'il en soit, la création / destruction d'un dico pour autant d'enregistrements rallonge beaucoup trop le temps d'exécution de ma requête, je n'utiliserais cette fonction que dans certains cas bien précis, notamment lorsque je souhaite vraiment fermer le plus rapidement possible ma connexion.

++

[Immobilis]

Et bien sûr, je suppose qu'il n'y a pas moyen de limiter cette rétention ?

Si, c'est possible. Mais bon... Il faut considérer cette valeur comme devant convenir à un maximum de situations. La modifier sous entendrait que quelque chose n'est pas très bien fait.

A+

[StephM_asp]

Je vois pas bien alors... Dans quel cas précis il serait intéressant de conserver une connexion ouverte 1m30 après que l'on en ait demandé la fermeture ?

[Immobilis]

Je vois pas bien alors... Dans quel cas précis il serait intéressant de conserver une connexion ouverte 1m30 après que l'on en ait demandé la fermeture ?

Pas de meilleur moyen que la preuve par l'image:
La latence permet de reservir l'internaute en données sans avoir à ouvrir de nouveaux ports (une connexion utilisateur = un port sur SQL Server). Dans l'exemple "Compteur1.GIF" j'execute une page deux fois. Le compteur de connexions que j'ouvre augmente, la deuxième fois non, car JE (personne d'autre) dispose encore des connections précédement ouverte. Au bout d'environ 90s d'inactivité les ports sont de nouveau disponibles pour un autre internaute.
Dans cet exemple, je consomme environ 90 ports sur les 3800 disponibles par défaut. En pratique, ce n'est pas chaque internaute qui consomme 90 connections, heureusement, mais il y a tout de même un risque de saturation.

La solution pour eviter de consommer est de créer le nombre de connections juste nécessaire.

A+