utilisation de PDO::ATTR_PERSISTENT

Salam;
page connexion nommée cbd.inc.php

Code:

---

1 2 3 4 5 6 7 8 9 10 11

..... // Options de connection $options = array ( PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8" , // indiquer à MySQL que echanger nos données en UTF8. PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION , PDO::ATTR_PERSISTENT => true );   $cbd = new PDO('mysql:host='.$PARAM_hote.';dbname='.$PARAM_nom_bd, $PARAM_utilisateur, $PARAM_mot_passe , $options );

---

l'utilisation de PDO::ATTR_PERSISTENT => true , mis l'appel de connexion en cache du serveur :
la mise en cache de l'appel est unique pour tous les utilisateurs ou un appel par utilisateur ?
quel est sa répercussion sur la charge de travail du serveur en cas de la mise en cache d'un appel par utilisateur ?
est ce que la mise en cache de l'appel pose un problème de sécurité ? :triste:

Salut

As tu lus ceci dans la doc de Php au sujet d'une connexion persistante ?
Connexions persistantes aux bases de données
Entre autre ce passage :

Citation:

---

Envoyé par Doc Php

Ceux qui ne sont pas rompus aux techniques des serveurs web et leur distribution de la charge de travail se font parfois une fausse idée de ces connexions persistantes. En particulier, les connexions persistantes ne permettent pas l'ouverture de plusieurs sessions avec le même lien ; elles ne permettent pas la réalisation de transactions efficaces et ne font pas le café. En fait, pour être extrêmement clair sur le sujet, les connexions persistantes ne vous donnent aucune fonctionnalité de plus que les connexions non persistantes.

---

De mon coté j'ai jamais utilisé de connexion persistante, plus par méconnaissance qu'autre chose.
Il me semble que les connexions persistantes s'y prêtent mal au fonctionnement du protocole HTTP, du moins quand cela se passe sur le réseau Internet, qui lui prend fin une fois que le serveur à répondu.


J'ai jamais trop su dans quel cadre (ou environnement) une connexion persistante améliorerait les performances sans dépasser la limite du nombre de connexion autorisé.
Peut être que sur un réseau intranet cela pourrait être fait et être intéressant.
Faut voir.

Citation:

---

est ce que la mise en cache de l'appel pose un problème de sécurité ?

---

Il me semble que ça n'est pas plus ou moins sécurisé qu'une connexion non persistante, les mêmes précautions doivent être prises.
Sauf erreur. ;)

Les connections persistantes ne sont pas vraiment là pour des raisons de performances mais plutôt pour tous les aspects de MySQL qui ont une durée de vie liée à la session comme par exemple les tables temporaires qui sont détruites quand la session se termine, l'usage des connections persistantes permet de les conserver d'une page à l'autre. C'est également très utile quand on travaille avec une transaction qui se déroule sur plusieurs pages.

Citation:

---

mais plutôt pour tous les aspects de MySQL qui ont une durée de vie liée à la session

---

Qu'est ce qui défini une session coté MySQL ?

Est-ce qu'il est possible par exemple de mettre en mémoire coté serveur (dans une session de Php par exemple) cette session pour pouvoir la ré-exploiter lors d'une demande ultérieur (un clic sur un lien par exemple) ?

Est-ce que sur un mutualisé c'est possible d'exploiter des connexions persistantes ou faut il un dédié ?
En somme, quel est le cadre ou environnement où une connexion persistante devient intéressante, utile (hormis les fonctionnalités qu cela offre) ?

Comme dit la doc, il me semble qu'on se fait une idée fausse de ce que représente une connexion persistante, mais la doc ne l'explique pas vraiment/clairement.

Je me suis mal exprimé. Il s'agit en fait de connexions et non pas de sessions (pour moi, ça englobe la même idée).

Le manuel nous dit:

Citation:

---

You can use the TEMPORARY keyword when creating a table. A TEMPORARY table is visible only to the current connection, and is dropped automatically when the connection is closed. This means that two different connections can use the same temporary table name without conflicting with each other or with an existing non-TEMPORARY table of the same name. (The existing table is hidden until the temporary table is dropped.) To create temporary tables, you must have the CREATE TEMPORARY TABLES privilege.

---

Donc nous devons garder la connexion ouverte entre deux page pour pouvoir réutiliser notre table temporaire, or la connexion est fermée à la fin du script, c'est pourquoi il existe cet attribut.

Malheureusement, il est impossible de stocker des ressources (fichiers, connection bdd, etc.) PHP sur session ou sur fichier pour la seule et bonne raison qu'il est impossible de les sérialiser.

Je pense que ça doit être possible également sur un serveur mutualisé, je vois pas pourquoi on pourrait pas, mais je n'ai jamais testé. On a rarement besoin des connections persistantes pour des sites web (c'est généralement les applis web qui en ont besoin).

Selon moi, les connexions persistantes sont utiles, comme je l'ai dit, quand on manipule des ressources "volatiles" du RDBMS (les tables temporaires et les transactions sont les deux seuls exemples qui me viennent à l'esprit mais il doit en exister d'autres, je ne suis pas vraiment un expert MySQL).

La documentation suggère que l'idée qui consiste à concevoir qu'une connexion persistante est une "mise en cache" de la connexion qui évite de la rouvrir à chaque fois est fausse. Personnellement, je n'ai jamais enregistré de gain de performances en utilisant les connexion persistantes. De plus, quand il s'agit d'optimiser les performances des requêtes, c'est pas là dessus qu'on va gagner quoi que ce soit.

Citation:

---

On a rarement besoin des connections persistantes pour des sites web (c'est généralement les applis web qui en ont besoin).

---

C'est ça qui m'étonne, du moins que je pige pas trop.
Si c'est une appli Web, ça suppose utiliser le protocole HTTP.

Ce que je comprends, à voir si cela est juste ou pas, c'est qu'en 1er cela dépend du comment est installé Php.
Apparemment si c'est en mode CGI, une connexion persistante ne sera pas possible, du moins ne servirait à rien (qui est souvent le cas des mutualisés il me semble).
Pour les autres on doit pouvoir l'exploiter.


Cependant, si on utilise le protocole HTTP (ou HTTPS, c'est pareil), je vois mal comment une connexion persistante deviendrait utile, je dirais que ce serait plutôt "casse gueule" (pour dire cela familièrement).


La raison, c'est le mode de fonctionnement de ce protocole qui lui est entièrement basé un échange loin d'être bi-directionnel (voire pas du tout).
En faite, le serveur attend une réponse, juste une réponse, et de l'autre, le client lui ne fait que faire une demande.
Donc le serveur n'interroge jamais le client, ce qui veut dire que coté serveur on ne sera jamais garanti que le client fasse une demande qu'on attendrait (une étape suivante par exemple).
C'est à mon sens un énorme handicap, et pas seulement pour les connexions.

Ca sous entend qu'il sera toujours possible de cumuler un nombre plus ou moins important de connexions sans qu'on ait la certitude que le client soit toujours là ou pas.
Une connexion est ouverte dans l'espoir que le coté client revienne l'exploiter.
On ne peu pas par exemple fermer des connexions si un client n'est plus là (coupure du réseau, ou encore ferme son navigateur).

Certes, une connexion persistante à un délai d'expiration (1 minute par défaut il me semble), mais ça peut causer un problème selon comment on prévoit les choses, sans compter qu'il y a un nombre max de connexions autorisées.

C'est en grande partie pour ça que je disais que le HTTP ne serait pas un bon contexte pour faire des connexions persistantes.
Mais c'est l'idée que je me représente.
Faut voir.