Discussion :

[flonardi]

Je souhaiterai savoir si un nombre de connexion/déconnexion trop important par jour peuvent détériorer les perfs sur la base. On a une appli qui effectue plus de 50000 connexions/déconnexions par jour. Est ce qu'une connexion prend de la place mémoire. Dans quelle plage mémoire se trouve t'elle(PGA, SGA,...)?

Dans une application, vaut'il mieux avoir une connexion persistante par utilisateurs ou une connexion qui ne dure que le temps de la transaction.

Merci

[LeoAnderson]

Oui, trop de connections c'est pas bon, puisque, par définition, c'est trop !

Plus sérieusement, les connections concurrentes utilisent de la PGA.
Une connection est relativement longue, mais cela pénalise surtout le client, pas le serveur.

Et il faut surtout savoir combien il y a de connections simultanées !

[edit]
Par contre, quand à la question est-ce qu'il vaut mieux une connection par session utilisateur ou par transaction démarrée, c'est clair que si vous avez 3000 utilisateurs concurrents, la session va "couter cher" en mode serveur dédié.
Donc, vous devez répondre aux questions suivantes :

1. Combien d'utilisateurs en tout
2. Combien d'utilisateurs en simultané (moyenne)
3. Type de session (est-ce que la session passe 90% de son temps à ne rien faire ou est-ce que la session est quasiment tout le temps active)

[/edit]

[driss.hazzaf]

Trop de déconnexions dégradent les perfs, car cela oblige une activité plus grande de PMON.
beaucoups de connexions dégradent les performances aussi, mais le degre de cette dégradation dépend de la configuration de votre base de données (dedicated servers ou MTS ).

[LeoAnderson]

Je ne serais pas aussi catégorique.

Bien sûr qu'une connection/déconnection a un impact sur la charge du serveur, mais cela n'est tout de même pas très couteux, voir même négligeable.
Si vos perfs s'écroulent parce qu'un client passe son temps à se connecter/déconnecter, c'est que le serveur.

[pifor]

Intéressant de voir que le Oracle® Database Performance Tuning Guide 10g Release 2 (10.2) mentionne comme la première (!) erreur trouvée dans les applications Oracle:

#

1. Bad Connection Management

The application connects and disconnects for each database interaction. This problem is common with stateless middleware in application servers. It has over two orders of magnitude impact on performance, and is totally unscalable.

Mais quelle application se connecte/déconnecte à chaque requête Oracle ???

Le top 10 complet: http://download-uk.oracle.com/docs/c....htm#sthref229

Dans une application, vaut'il mieux avoir une connexion persistante par utilisateurs ou une connexion qui ne dure que le temps de la transaction.

Plutôt une connexion persistante.

[LeoAnderson]

Plutôt une connexion persistante.

Dans une application, vaut'il mieux avoir une connexion persistante par utilisateurs ou une connexion qui ne dure que le temps de la transaction.

Attention en server dédié dans ce cas !!!
il ne faut donc pas tirer de conclusions hâtives et bien connaitre le nombre de connections, de connections actives et de transactions attendues ...

[flonardi]

En réponse à LeoAnderson
1. Combien d'utilisateurs en tout
>> on doit avoir 120 utilisateurs distinct en moyenne
>> qui utilise environ 250 connexion suivant le nombre d'application qu'ils chargent

2. Combien d'utilisateurs en simultané (moyenne)
>> en simultané, cela signifie status='active' dans v$session. Si c'est ça, on a en général pas plus de 5 utilisateurs en même temps qui exécutent des requêtes. Mais comme c'est surtout du transactionnel, on ne peut quantifier.

3. Type de session (est-ce que la session passe 90% de son temps à ne rien faire ou est-ce que la session est quasiment tout le temps active)
>> 90% à ne rien faire.

Sinon, j'ai un autre question du même ordre:
nous fonctionnions en dedicated server puis lorsque nous sommes passés de HP à IBM (sous Linux), on a rencontré pas mal de soucis de perf (swap essentiellement lors des montées en charge). Du coup, on est passé en MTS afin de générer des pools de connexion. Le Soucis est que lors de grosses requêtes importantes pour la production et qui doivent se lancer en cours de journée, le MTS n'est pas adapté car le risque est que les "petites requêtes" soient en attente derrière les "grosses requête".

Quand aux connexions, les développeurs ont prévu de suivre le schéma suivant:
création de la requête -> connexion -> exécution -> retour des données->déconnexion

Est ce que la seule solution de créer un pool de connexin sous Oracle est le MTS car j'ai lu un article comme quoi le MTS était obsolète. Qu'en pensez-vous.
Le lien: http://www.dba-oracle.com/t_mts_mult...ers_shared.htm

(Nous sommes en oracle 9.2.0.6)