Bonjour,
 
Jusqu'à présent je ne m'étais jamais réellement posé la question, je faisais avec les sessions parce que ben voilà cela semble évident que ça améliore les perfs d'aller directement dans la mémoire plutôt que d'effectuer une requête.
Mais si on tient compte des problèmes de sécurité, de la duplicité des informations, de l'asynchronicité des informations et du fait qu'en général on ne substitue que des requêtes simples et rapides, les sessions PHP sont-elles vraiment intéressantes ?
 
J'ai rapidement cherché sur Google mais je ne trouve que des benchmarks qui testent les sessions entre elles en fonction de leur configuration de stockage. Le gain par rapport à un site fonctionnant sans est-il réellement intéressant ? Parce qu'au finale on ne stocke pas tant de choses dans les sessions.

Lu,
 
pourquoi parler de gain(s) ou de benchmarks ? Les sessions fournissent avant tout une fonctionnalité. En effet, pour rappel, HTTP est un protocole dit sans état, c'est-à-dire qu'on a aucun moyen direct d'associer quelque chose à un client entre deux de ses requêtes. Il existe les cookies mais ils sont limités sur un certain nombres de points et c'est le client qui les stocke/réenvoie (= pas approprié pour des données +/- sensibles, il pourrait les modifier ou forger). C'est là qu'entre en jeu les sessions : espace de stockage théoriquement illimité (on est loin des 4 ko d'un cookie) et elles sont stockées côté serveur (= sûr).
 
Les utiliser comme cache, oui, c'est envisageable mais effectivement, pour que ça ait un sens, il faut que ces données soient propres à l'utilisateur.

À la base, ça reste un cookie pour charger la session, ou alors un GET.

Ce que je veux dire c'est, est-ce qu'une identification par un token dans un cookie à chaque page puis ensuite faire les requêtes qui vont bien vers la bdd c'est vraiment significativement plus lourd que de lancer l'identification par cookie puis charger une globale qu'on va balader de page en page ?

Mouais, ne pas confondre la session et la partie propagation de l'identifiant non plus. Et en GET c'est déconseillé et limite déprécié.
 
C'est difficile de répondre, ça dépend de trop nombreux facteurs  :
* où sont stockées les sessions (en RAM, autre serveur, fichiers, sur quel type de HDD, etc)
* du trafic/charge : le but étant que l'ensemble ne tombe pas au premier pic venu
* la base de données elle-même
 
De manière générale, stocker les données dans une base (SQL), je pense que c'est une mauvaise idée :
* ce sont des requêtes/trafic en plus (= t'y perds généralement)
* si tu veux quelque chose de cohérent/fiable, tu dois faire les opérations dans une transaction, ce qui est plus coûteux (verrou, exactement comme les fichiers)
 
Stocker les données de session en base est facile à faire, il suffit d'écrire un gestionnaire (des callbacks à écrire - ou une interface à implémenter) mais je n'ai jamais vu quelqu'un en dire qu'il y avait gagné en terme de perfs (pour une bdd SQL).

Oui moi je parle du côté où la session sert à garder les données d'un utilisateur récupérées dans la bdd.
 
Et la question est : est-ce que cela se ressent vraiment sur la navigation et/ou la charge serveur de ne pas stocker le résultat des requêtes dans les variables de session ?
Dans la mesure où je n'ai pas besoin de trimbaler de page en page des infos qui ne sont pas dans le bdd, et que j'ai peu d'infos redondantes à récupérer à chaque fois (les classiques : id, nom, préférence de langue, préférence de date, droits, etc.) je me demande si j'implémente ou non les sessions.

Ok.
 
L'avantage c'est que tu économises une requête SQL par requête HTTP, c'est plus avantageux.
 
L'inconvénient c'est que les informations en session pourraient ne pas être à jour.

Non mais c'est le contraire que je veux faire. xD
 
Je veux faire tout plein de requêtes SQL au lieu d'aller récupérer les données de session. Mais la question est, au final, quand on prend tout en compte, est-ce que ces quelques requêtes SQL supplémentaires pénalisent vraiment l'utilisateur et/ou le serveur ? Je ne suis pas certain que les pertes de perfs (à mon avis minimes) soient réellement prépondérantes devant le gain d'unicité des informations.

Pour moi, la session est indispensable pour conserver le lien d'identification, la session utilisateur. Mais en-dehors de l'identité de la personne (nom, prénom et 2-3 autres données qui dépendent de la fonction du site web/outil), je ne stock rien d'autre dedans.

@MaybeEijOrNot

Les framework récents gèrent souvent cette partie via cookie avec une durée de vie très courte.
Et le cookie en question ne contient pas de données en clair, elle sont chiffrées pour éviter la manipulation par le navigateur/l'utilisateur (ce dont parlait @pluj).
Via une "passphrase" ou un "salt" dans un fichier de configuration.

Après je pense que tu prends le problème à l'envers: tu seras obligé de faire ces requêtes pour être sûr d'avoir une information à jour quand ton code s'exécutera.
C'est (de mon point de vue) bien plus important d'avoir une information à jour qu'une latence (je préfère répondre une information correcte en prenant un peu plus de temps plutôt que de risquer de donner une information non à jour mais plus vite)
Si tu ne peux pas encaisser la charge liées à ces chargement de profils utilisateurs, c'est que soit le serveur web et/ou de base de données ne sont pas adaptés à la volumétrie de requête à traiter.

Et c'est là ou il faut faire des compromis. Par exemple, sur beaucoup de sites, c'est la gestion des droits de l'utilisateur qui est souvent assez gourmande en temps de traitements.
Et plutôt que de charger ces informations à chaque hit sur le serveur, ces sites prennent le parti de dire que l'utilisateur devra à nouveau se connecter si jamais de nouveaux droits lui ont été attribués.
C'est un choix comme un autre. Tout dépend d'où se trouve ton intérêt.

Mais si on considère que tes droits sont dans des tables hiérarchisées et dépendantes de groupes utilisateurs elles aussi hiérarchisées, là clairement on ne parle plus de faire un select dans un base sur la base d'un login et d'un mot de passe.
Et oui, à ce stade, dans ta session, c'est bien plus intéressant de stocker la liste des droits une fois les bonnes requêtes faites plutôt que de refaire X requêtes à chaque hit pour avoir ces mêmes droits.

Une autre façon de procéder consiste à donner un temps de vie à l'information au sein de la session qui a elle aussi sa durée propre. Le but ici sera juste de rafraîchir certaines informations de la session quand un certain temps sera passé depuis sa génération.

Bref la session est très intéressante, et elle permet finalement de contourner le côté sans état du protocole HTTP.
Rien que l'exemple que j'ai donné ici le montre. Les forums, les wordpress, beaucoup l'utilisent parce que ça marche.

A toi de voir ou se trouve son intérêt et où sont tes contraintes