[Résolu] Sessions

Bonjour à tous

Lorsque je participais à la normalisation et à l'implémentation des protocoles de communication dans les années 1975-1985, la couche "session" était le point fondamental de toute communication entre un terminal (sans grande autonomie) et un ordinateur central, qui gérait lui même la base de données. Cette "couche session" était réalisée sous la forme d'une structure de données sur l'ordinateur central, similaire à ce qui existe sous la forme de $_SESSION sur les serveurs actuellement.

L'évolution des techniques a perturbé le modèle conceptuel de cette époque.
Pour autant que je comprenne, le concept de "session" est actuellement réparti entre :
- le navigateur du client sous la forme du "sessionStorage"
- le serveur sous la forme de "$_SESSION"
- le gestionnaire de base de données, sous la forme d'une connexion établie par le serveur sous la forme d'un objet PDO, le gestionnaire de base de données ayant lui même une structure similaire à $_SESSION lui permettant d'établir une continuité des échanges sur cette connexion.
De plus nous avons sur le serveur des objets PDOStatement qui représentent des objets similaires sur le gestionnaire de base de données -- du moins c'est ce que je crois comprendre à la lecture de la documentation.

Si on ne fait rien de particulier, à chaque interaction entre client et serveur nécessitant un appel à la base de données, il faut recréer un PDO et des PDOStatements qu'on avait créés dans des interactions précédentes.

Question: est-il possible (et judicieux) de mettre des objets PDO et PDOStatment dans $_SESSION sur le serveur, ce qui permettrait de réduire l'overhead généré par ce mécanisme ?

Merci de m'aider à clarifier mes idées sur ce sujet.

C’est ce que je pensais, mais je préférais avoir une confirmation pour éviter de me lancer dans un développement inutile.
Ce n’est pas une affaire de microsecondes, mais de millisecondes car chaque fois qu’on accède à la base de données il y a des échanges sur le réseau, le gestionnaire de base de données n’étant pas sur la même machine que le serveur. Dans mon cas c’est effectivement sans grande importance compte tenu de la faible taille de la base.
Ça veut dire aussi que préparer des statements avec placeholders n’est pas aussi intéressant que j’espérais puisqu’il faut les rebâtir à chaque transaction.
Par contre j’ai l’intention de stocker les objets PHP dans $_SESSION pour ne pas avoir à les rebâtir à chaque transaction avec des accès à la base.
Votre avis ?

Je ne vais pas débattre sur milli/microsecondes qui me semblent de l'enculage de mouches. Les cas utiles de connexions persistantes aujourd'hui me semblent être: connexion à un SGBD lourd (Oracle d'entreprise, Postgresql, etc.), applications avec requêtes à haute fréquence (jeu, chat, etc.).

a écrit :
Ça veut dire aussi que préparer des statements avec placeholders n’est pas aussi intéressant que j’espérais puisqu’il faut les rebâtir à chaque transaction.

On les utilise rarement pour cet avantage en effet, mais pour l'autre: Les variables ainsi insérées ne sont pas évaluées et empêchent donc l'injection de code.

a écrit :
Par contre j’ai l’intention de stocker les objets PHP dans $_SESSION pour ne pas avoir à les rebâtir à chaque transaction avec des accès à la base.

Comme je l'ai dit ce n'est pas possible directement, il faut d'abord linéariser les objets:

$object = new Truc();
$_SESSION['truc'] = serialize($object);
…
…
$object = unserialize($_SESSION['truc']);

Si les propriétés contiennent elles-mêmes des pointeurs ou des références il faut gérer cela en utilisant les fonctions magiques __sleep et __wakeup.

Ce n'est pas impossible mais on a meilleur temps de penser nos applications le plus «stateless» possible, ce qui les rendra bien plus compatible avec la nature de HTTP et de php. La plupart des applications modernes reconstruisent tout à chaque requête, c'est plus simple à déboguer et à maintenir. Pour optimiser les performances, quand c'est nécessaire, on met plutôt un cache devant.

Mais si tu as des objets simples avec quelques propriétés contenant des types de base, pourquoi pas.

J’ai déjà utilisé des objets un peu complexes sans problème dans $_SESSION, sans aucun problème. Ils sont automatiquement linearisés â la mise dans $_SESSION et délinearisés à la lecture, la seule condition étant que la définition des classes se trouve avant l’ouverture de la session.
Pour ce dont j’ai besoin, c’est tout à fait approprié.

On voit bien la différence de générations: jusque 1990, la vitesse des lignes de transmission était au mieux de 9600 bits par seconde. Il était très important de limiter le nombre d’accès à distance, et même les entrées sorties sur disque étaient très lentes, on essayait d’en réduire le nombre. Et du reste c’est toujours vrai compte tenu de l’augmentation de la vitesse des CPU. Mieux vaut un long calcul qu’une entrée sortie.

Ces considérations vous semblent futiles mais resteront pour moi des choses qui ont un sens. Quand je vois les monstres que sont les PC en puissance, taille mémoire et capacité de disques et qu’on voit combien ils rament pour effectuer des tâches très simples... quand nous programmions à la fin des années 1960 des machines devant exécuter des programmes en temps réel, le design tenait compte de ces facteurs. Je suppose qu’il en est toujours de même dans les ordinateurs d’une avion ou d’une fusée
D’accord je radote, il est temps d’aller se coucher !

PapyJP a écrit :
Bonjour à tous

Lorsque je participais à la normalisation et à l'implémentation des protocoles de communication dans les années 1975-1985, la couche "session" était le point fondamental de toute communication entre un terminal (sans grande autonomie) et un ordinateur central, qui gérait lui même la base de données. Cette "couche session" était réalisée sous la forme d'une structure de données sur l'ordinateur central, similaire à ce qui existe sous la forme de $_SESSION sur les serveurs actuellement.

L'évolution des techniques a perturbé le modèle conceptuel de cette époque.
Pour autant que je comprenne, le concept de "session" est actuellement réparti entre :
- le navigateur du client sous la forme du "sessionStorage"
- le serveur sous la forme de "$_SESSION"
- le gestionnaire de base de données, sous la forme d'une connexion établie par le serveur sous la forme d'un objet PDO, le gestionnaire de base de données ayant lui même une structure similaire à $_SESSION lui permettant d'établir une continuité des échanges sur cette connexion.
De plus nous avons sur le serveur des objets PDOStatement qui représentent des objets similaires sur le gestionnaire de base de données -- du moins c'est ce que je crois comprendre à la lecture de la documentation.

Si on ne fait rien de particulier, à chaque interaction entre client et serveur nécessitant un appel à la base de données, il faut recréer un PDO et des PDOStatements qu'on avait créés dans des interactions précédentes. Notepad++ Malwarebytes FileZilla

Question: est-il possible (et judicieux) de mettre des objets PDO et PDOStatment dans $_SESSION sur le serveur, ce qui permettrait de réduire l'overhead généré par ce mécanisme ?

Merci de m'aider à clarifier mes idées sur ce sujet.

Il existe cependant des moyens de déclarer la connexion comme persistante. Cependant cela exige de gérer le nombre maximum de connexion parallèles possibles, de fermer judicieusement les connexions pour éviter d'avoir son serveur saturé et le site inutilisables, etc. Quelques microsecondes d'overhead ne me semblent pas un grand sacrifice pour la performance, si tu n'es pas sur un hébergement mutualisé, il faut juste t'assurer que le serveur de db et le site soient proches (idéalement dans un même réseau local).
Modifié par hikolipotu (19 Jan 2019 - 20:47)

Bonsoir
Je comprends que ces points qui sont fondamentaux en informatique temps réel sont secondaires dans le monde applicatif et que l’augmentation des performances CPU et réseau permet de faire des choses que nous aurions considérées comme des hérésies dans les environnements dans lesquels j’ai passé l’essentiel de ma carrière.
Au premier chef, utiliser une base de données relationnelle pour un ensemble de données qui tient dans une dizaine de fichiers dont le total est de l’ordre d’un mégaoctet revient à abandonner tout concept de performances.
Je vais donc faire comme si ces problèmes n’avaient aucune importance et je verrai bien le résultat.