Discussion :

[Ludosjob]

Bonjour,

j'ai développer un e-commerce il y a quelques années en asp et access.
A ce moment là j'avais cru bon de stocker la connexion à la base dans une variable de session.
Ce qui veux dire que la connexion à la base est persistante pendant toute la durée de la session.
Aujourd'hui le site reçoit des piques de connexion de plus de 200 sessions ouvertes simultanément,
donc autant de connexion à la base.

Or j'arrive au limite de se que peux supporter access, le site rame.

J'ai dans l'idée de modifier cela en créant une connexion par page asp qui durera donc le temps de charger les données.
Le temps de la connexion sera donc de quelques secondes, le temps de faire les requetes.
Par contre elle se répétera à chaque pages lancée par un utilisateur.

Avant de me lancer dans ce chantier qui va malheureusement demander de modifier toutes les pages asp du site qui se connecte.
J'ai lu que par defaut la base access garde la connexion ouverte environ 10min pour des soucis de perf justement.

Donc est-ce judicieux de procéder ainsi ? cela risque t-il d'etre encore plus gourmand ?
Est-ce que ca va vraiment changer quelque chose ? si access garde la connexion ouverte et fourni la meme connexion à la
page suivante ?

J'avais dans l'idée d'utiliser une class DB_factory qui fournirait un service d'accès et avec du coup
un timeout de pas plus de 5 minutes pour soulager la base, enfin si c'est possible.

J'attend vos conseils,

merci,

Ludo.

[Immobilis]

Salut,

Tout d'abords, evidement pas de connexion en session.

Ensuite, oui, une factory c'est bien. Il y a unexemple un peu abouti ici: http://www.developpez.net/forums/d50...s-sources-asp/

Une connexion par page, transmise à tous les morceaux de code qui en ont besoin.

Dernier conseil, change de base de données. Access n'est pas prévu pour gérer beaucoup d'utilisateurs: SQL Server, voir MySQL, comme tu veux.

A+

[Poumtschak]

Tout d'abord, évidement pas de connexion en session.

Bonjour,

Je me permets de remonter ce fil car je suis surpris de cette réponse alors que mon bouquin de référence sur ASP (qui n'en est peut-être pas une) suggère exactement le contraire et déconseille d'ouvrir une connexion par page.

Pour une toute petite appli ASP sur base Access 97 - un héritage - avec très peu d'utilisateurs (<5), j'ai empiriquement pris l'option de stocker les connexions en variable de session. Cependant, vu la lenteur lors d'une paire d'accès concurrents, je soupçonne un problème là-dessus (ou sur les options de curseur/verrou mais je n'y connais rien ).

Merci de m'éclairer sur les bonnes pratiques en la matière.

NB: j'ai bien commencé à envisager une migration de la base sur SQL Server 2005 Express Edition, mais le rapport complexité de mise en œuvre / gain attendu me paraît quelque peu excessif pour nos besoins.

[Immobilis]

Il faut faire la différence entre variables de session (une pour chaque utilisateur) et d'application (une seule commune pour tous les utilisateur).

A mon avis les deux ne comportent que des inconvénients.

• Session: cette variable est accessible uniquement par l'internaute qui la créé en arrivant sur le site. Elle reste active pendant un temps défini dans IIS (20 minutes par défaut) ou dans chaque page. Ce qui veut dire que même quand l'internaute part, la connexion reste ouverte et inutilisable pour les autres visiteurs.
• Application: tous les internautes utilisent la meme connexion les uns après les autres. Une connexion ne peut traiter qu'une seule requete à la fois. Ca risque de faire des embouteillages...

Une seule chose à retenir. Si on ne se sert pas d'un objet quel qu'il soit, il ne doit pas exister.

A+

[roro06]

Bonjour

Sans aller jusqu'à critiquer le bouquin de référence que tu cite, c'est bien la première fois que je vois conseiller une connection à une BDD en variable de session, et pire encore en variable d'application. Si à chaque fois que google passe sur ton site (et yahoo, et MSN, etc ...) pour indexation, une connexion est créée, et dure le temps de la session (20mn par défaut, mais c'est modifiable), ou tout simplement un internaute qui passe "par hasard", heu ... j'ai peut-être du mal avec le concept d'optimisation. D'autant que les variables d'application et de session ne sont pas indexées, ce qui signifie qu'elle sont rangées dans un tableau, et que lorsqu'on en appelle une, ASP va défiler tout le tableau jusqu'à trouver ce qu'il cherche. Vous avez dit "performances" ?

200 connexion simultanées à ACCESS ? t'es sûr de ton coup, là ? Je croyais que la limite était de 32.

Perso, et on m'a toujours conseillé de faire ainsi, j'ouvre et referme ma connexion dans chaque page.

Si tu attends du trafic, je rejoinds immobilis : change de BDD. ACCESS a des performances assez impressionnantes en interrogation, mais ça s'arrête là. Il existe des utilitaires de migration vers SQL server, mySQL etc ...

Le temps de la connexion sera donc de quelques secondes

D... merci, c'est quand même beaucoup plus rapide que ça (définis les bons index !)

Voili voilou, c'était mon humble avis

[Poumtschak]

Tout d'abord, puisqu'il semble y avoir confusion, je précise que je ne suis pas l'auteur du post original, et que mon contexte n'est pas le même (à savoir : application plutôt bricolée, intranet et très faible nombre d'utilisateurs).

Ce qui ne dispense pas de continuer à glaner des informations sur les bonnes pratiques auprès des spécialistes.

Au niveau du positionnement des connexions, j'ai cru comprendre que - quelle que soit la méthode choisie - interviennent plusieurs dispositifs de cache par IIS, le fournisseur d'accès à la BDD, le système hôte, etc. En effet, j'ai remarqué que lors de la mise à jour de listes déroulantes via AJAX, pour une requête avec des paramètres identique le système récupérait les données beaucoup plus rapidement après la requête initiale.

Pour en revenir au bouquin, dans la page suivante (pas dispo sur Google Books), l'auteur(e) se contredit en déconseillant l'ouverture d'une connexion au niveau session en cas d'utilisation d'OLE DB, cette dernière solution gérant parait-il les pools de connexion de façon transparente.

En somme, tout ceci est pour le moins confus pour l'amateur mal éclairé.

Merci de vos... éclaircissements.

[Immobilis]

Ben j'ai pas grand chose à ajouter que ce que j'ai déjà dit.

Tu veux savoir quoi de plus?

Au niveau du positionnement des connexions, j'ai cru comprendre que - quelle que soit la méthode choisie - interviennent plusieurs dispositifs de cache par IIS, le fournisseur d'accès à la BDD, le système hôte, etc. En effet, j'ai remarqué que lors de la mise à jour de listes déroulantes via AJAX, pour une requête avec des paramètres identique le système récupérait les données beaucoup plus rapidement après la requête initiale.

Ok, mais ça change rien aux fondamentaux.

en cas d'utilisation d'OLE DB, cette dernière solution gérant parait-il les pools de connexion de façon transparente.

En ASP3 c'est pas très clair...

A+