Poster une réponse à un sujet: Appli web : connexion à la DB persistante ou pas ?
Attention, ce sujet est un sujet ancien (1526 jours sans réponse)
Gras [b]Texte[/b] Italique [i]Italique[/i] Souligné [u]Souligné[/u] Barré [strike]Barré[/strike]
Courriel [email=nobody@nobody.org]Nom[/email] Lien [url=http://www.website.com]Texte[/url] Ancre [anchor]Nom[/anchor] Image [img]http://www.website.com/image.jpg[/img] Insérer une image en provenance du site
Aligné à gauche [align=left]Texte[/align] Centré [align=center]Texte[/align] Aligné à droite [align=right]Texte[/align] Toute la largeur [align=justify]Texte[/text]
Couleur [color=#000000]Text[/color] Mise en forme [highlight=pascal]Texte[/highlight] Widgets Emoticons :code: [:code] Convertisseur HTML vers BBCode Convertisseur Word vers BBCode
Prévisualisation Vérification de l'orthographe

Copier Coller Couper Tout sélectionner
Tout effacer Insérer la date Insérer l'heure Insérer la date et heure Insérer votre IP
Liste [list=square][item]BlaBla[/item][/list] Liste Numérotée [list=decimal][item]BlaBla[/item][/list]
Citation [quote=name]Texte[/quote] Spoiler [spoiler]James est le meurtrier![/spoiler]
Tout en majuscules [uppercase]Texte[/uppercase] Tout en minuscules [lowercase]Texte[/lowercase] l33t [l33t]Je suis un nerd[/l33t] Texte en indice [sub]Texte[/sub] Texte en exposant [sup]Texte[/sup] Taille du texte [size=8]Texte[/size]
 
gizmo
OK merci :smile:
J'ai lu par ailleurs que les connexions persistentes pouvaient être dangereuses car on ne sait pas toujours si on récupère une connexion "stable" (quid si l'appli qui l'a ouverte précédemment a planté en plein milieu d'une transaction, ce genre de choses). :ohwell:


Non. C'est justement le boulot d'un connection pool (en combinaison avec le transaction manager).
Que ce soit transparent pour toi (instrumentation du code) ou explicite, le connection pool ne doit pas allouer une connexion à quelqu'un d'autre si elle n'a pas été relâchée correctement. Au-dessus de cela, il y a une gestion interne de restauration des sessions (en cas de connection perdue, par exemple) ou de réaliser les commit/rollback nécessaires.
zion
L'appli ouverte? Benh c'est toi qui doit gérer ça, ça se partage pas entre appli, c'est typique à PHP, en dehors de PHP c'est toi qui gère de garder un socket ouvert tu sais :ocube:

Mais comme ouvrir un socket, ça coûte "cher", au final, ça se gagne. A toi d'avoir un bon try/catch et du code propre, mais si t'as un code moisi, ça, c'est sûr que bon :ddr555:
ovh
OK merci :smile:

En fait il y a 2 applis : un webservice en java faite par une autre boîte (c'est elle qui a planté principalement), et une appli à moi en PHP mais qui provoque bcp moins d'accès (la première est publique on va dire, l'autre pas et ne sert qu'à une poignée de personnes).

J'ai lu par ailleurs que les connexions persistentes pouvaient être dangereuses car on ne sait pas toujours si on récupère une connexion "stable" (quid si l'appli qui l'a ouverte précédemment a planté en plein milieu d'une transaction, ce genre de choses). :ohwell:
zion
Je dirais que la réponse est dépendante de ton archi, et de ses possibilités. Ton truc est en PHP, ou en natif?

Si c'est en PHP, t'as pas beaucoup de choix, mais il y a une connexion persistante qui permet de ne pas s'énerver, si t'es en FastCGI, logiquement il garde cela de page en page, tu gagnes quelques ms précieuses sur la connexion, et tu vas pas te prendre 200 connexions vu que t'es limité en termes de FastCGI.

En compilé je fais plus ou moins pareil, j'ai un pool de connexions ouvertes, et je vais pêcher dedans à chaque query. Si t'utilises l'API C, tu dois bien faire gaffe à ce que tu fais, pour pas exploser le bousin en demandant le result du query (qui est du dernier, donc si t'es en multithread benh.... pas forcément celui que tu crois :grin: ).

Dans d'autres cas je préfère le mode connecté/déconnecté, mais en fermant au bon moment (dès que je sais que j'ai fini, pas en fin de process), ça me permets de pas trop charger la mémoire. Mais dans les grandes lignes, le persistent a souvent ma préférence :smile:
ovh
Salut les nerds :petrus:

Au boulot, on me pose une question à laquelle j'ai du mal à répondre : pour une appli web, vaut-il mieux utiliser un mode de connexion persistent à la base de données (utilisant un pool de connexions par appli), ou un mode où on se connecte et déconnecte à chaque requête http (qui est me semble-t-il le mode par défaut pour des applis PHP) ?
J'ai fait quelques recherches sur le sujet, mais il ne semble pas y avoir de consensus clair sur le sujet.

A la base, cette question fait suite à une appli qui a planté suite à un afflux massif de connexions simulatanées provoquant une erreur "too many connections" de mysql. En fait je pense que le problème provient principalement d'un rafraîchissement automatique continu d'une liste d'items qui est à mon avis codé sans cache et provoquer des tas de "select"... Je leur ai suggéré d'intercaler un cache comme redis, mais on m'a aussi parlé du mode de connexion à la base, d'où ma question.

Merci pour vos avis :dawa:
Catégorie :  






Ada
CSS
Cobol
CPP
HTML
Fortran
Java
JavaScript
Pascal
Perl
PHP
Python
SQL
VB
XML
Anon URL
DailyMotion
eBay
Flickr
FLV
Google Video
Google Maps
Metacafe
MP3
SeeqPod
Veoh
Yahoo Video
YouTube
6px
8px
10px
12px
14px
16px
18px
Informaticien.be  - © 2002-2019 Akretio SPRL  - Generated via Kelare - Hosted by Verixi Internet Services
The Akretio Network: Akretio  - Freedelity  - KelCommerce  - Votre publicité sur informaticien.be ?