variable de session combien un serveur peut en supporter?

[webmasterdemonsite]

bonjour

je suis en train de develloper un site qui utilisera pas mal de variables de sessions sous forme de tableau du genre:

$_SESSION['tableau'][x][y]

ma premiere question:

est ce que $_SESSION['tableau'][x][y] est considéré comme une seule variable ou plusieurs?


et surtout:

combien peut supporter un serveur dédier de variables de sessions?

imaginons que j'ai 3000 internautes connectés en session et que chacun utilise 4 variables du type $_SESSION['tableau'][x][y]
(ca fait donc 12000 variables du type $_SESSION['tableau'][x][y] )

est ce bien raisonnable?

bon week end ;-)

 

[jcaron]

Chaque session est sauvegardée sous forme d'un fichier dans un dossier (genre /tmp, cf session_save_path() pour savoir où exactement sur ton serveur). Evidemment php ne charge que les variables de session correspondant à un utilisateur à la fois (par processus), mais évidemment ça prend plus de temps de désérialiser (et sérialiser à la fin) quelques Mo à chaque requête que quelques dizaines d'octets, donc je pense qu'il vaut mieux que tu restes raisonnable...

Jacques.

 

[webmasterdemonsite]

salut

merci, je ne connaissais pas session_save_path() ....

je vais tester tout ceci, mais effectivement il va falloir que j'y aille molo sur les sessions en forme de tableau

sinon il y a la solution des cookies et du javascript mais je prefererais m'en passer...

merci beaucoup de ton aide !

a+

bon week end ;-)

 

[jcaron]

Ben lis un peu la doc, tu verras, on y apprend plein de choses. C'est par là: http://www.php.net/manual/en/index.php

Les tableaux ce n'est pas gênant en soi, tout dépend de leur taille. Si tu as quelques valeurs ou quelques dizaines de valeurs, ça ne devrait poser aucun problème. Si tu en as des milliers et plus, ça va commencer à bouffer du CPU, pas forcément pour grand chose (mais comme on ne sait rien de ton appli, c'est difficile à dire).

Si tu as beaucoup de données, les transmettre dans un ou plusieurs cookies c'est probablement encore pire. Non seulement il va falloir sérialiser/désérialiser tout ça de la même façon, mais en plus à chaque requête (y compris pour les fichiers statiques genres images etc.) le client va te rebalancer ça, et ça chaque fois que tu modifies une variable (ou tout le temps si tu ne sais pas trop s'il y a du changement ou pas) tu dois le rebalancer dans l'autre sens. Ca peut faire beaucoup de bande passante utilisée pour pas grand chose.

Mais comme déjà dit, comme on n'a aucune idée de ce que tu veux faire, de la quantité de données impliquées, tout ça reste très vague...

Jacques.

 

[webmasterdemonsite]

encore merci

Mais comme déjà dit, comme on n'a aucune idée de ce que tu veux faire, de la quantité de données impliquées, tout ça reste très vague...

gros gros projet qui va me prendre 1 an ou 2 de boulot... :wink:

 

[Leonick]

Après, à voir si la session est ce qu'il y a de plus indiqué pour conserver beaucoup de variables. L'internaute aura-t-il besoin de récupérer une partie de ces infos ultérieurement ? si oui, il faudra bien qu'elles soient conservées ailleurs qu'en session, qui a un délai d'expiration assez court.
Via les cookies, ça n'est pas très sécurisé, en plus, s'il veut pouvoir récupérer ses infos depuis une connexion d'un autre ordinateur ?

 

[webmasterdemonsite]

merci à vous deux,

je vous embête avec une derniere question ;-) :

je me demande pourquoi l'acces aux variables de sessions est beaucoup moins long en terme de temps que l'acces aux donnée d'un base mysql5.1 ...

bon dimanche

 

[jcaron]

Variable de session:
- open
- read
- close
- deserialize

Accès SQL:
- ouverture connexion BDD
- open client
- accept serveur
- authentification
- composer requête
- envoyer requête client
- recevoir requête serveur
- parser requête
- composer arbre d'exécution
- exécution
- open index
- seeks + reads index
- close index
- open heap
- seeks + reads heap
- close heap
- filtres
- composer réponse
- write réponse serveur
- lecture réponse client
- parser réponse client
- close serveur
- close client

Ceci dit, ça se voit difficilement à l'oeil nu si tes requêtes utilisent des index et tout ça, mais si tu en fais vraiment beaucoup c'est clair que ça se voit. Mais l'utilisation de la bdd te permet:
- d'avoir des données partagées entre plusieurs utilisateurs
- de séparer le serveur http du serveur sql
- d'utiliser plusieurs serveurs sql qui partagent les mêmes données
- de gérer les propriétés ACID de la base de données
...

Entre les deux, tu peux utiliser des solutions comme memcache qui permettent de mettre en cache partagé les réponses de la bdd, et qui est nettement plus rapide.

Jacques.

 

[webmasterdemonsite]

whouaou ! merci encore mille fois!

comment connais tu tout ceci ?

vraiement merci pour toutes tes réponses !

bonne fin de dimanche

 

[jcaron]

C'est marqué dans la doc

Jacques.

 

[julienr]

si tu penses accéder à 3000 sessions simultanées à terme, c'est plus qu'un conseil de mettre les sessions en base, 3000 utilisateurs sur un même serveur c'est déjà bcp, alors le faite de centralisé peut te permettre de répartir la charge sur plusieurs serveurs facilement sans avoir à attribuer un serveur particulier à ton client, aussi mysql comme le dit jacques fait tout cela mais généralement qu'une seule fois, lorsque c'est répétitif les plans d'éxéctions et les données sont mise en mémoires et pour cela on peut faire confiance à MySQL

 

[webmasterdemonsite]

bonjour

c'est plus qu'un conseil de mettre les sessions en base

que signifie "mettre les sessions en base" ?

bon week end

 

[julienr]

salut,

Ce que j'appelle sauvegarder les sessions en base c'est concrètement utiliser la fonction php session-set-save-handler qui peut te permettre de redéfinir le comportement normal de php vis à vis des sessions c'est à dire de les sauvegarder sous forme de fichier texte sur le serveur, localement. Sauvegarder les sessions en base te permettrait facilement de centraliser celles-ci surtout si par la suite ton application web nécessite plusieurs frontaux. Aussi en utilisant cette fonction tu pourrais parfaitement en fonction de la clé de session optimiser le stockage dans une colonne spécifique de la base de données pour un accès direct et ceci sans sérialisation / désérialisation, and so on...

 

[webmasterdemonsite]

merci julienr !