OVH Community, votre nouvel espace communautaire.

A propos de 'session.save_path'


testeur115
12/12/2013, 08h31
@Nowwhat enfaite meme avant php 5.4, je ne vois pas l'interet de faire un tache cron pour netoyer alors que le gc le fait bien tout seul ?

testeur115
11/12/2013, 14h39
Citation Envoyé par Nowwhat
Avant, on a pu exécuter un 'ls -al /tmp'** pour 'voir' ces fichiers - sans aucun autre droit.
Le résultat été hallucinant.
Des centaines des milliers des fichiers de sesson de tout le monde.
Humm ce temps est très loin j'espère ? car c'était pas top nivo sécu ça...



Dans ce répertoire /tmp comment sont différencier les sessions de tel ou tel site ???

testeur115
11/12/2013, 08h46
Citation Envoyé par Nowwhat
Il faut savoir qu'un fichier session (typiquement nommé sess_0tjoubtttd9k2i2enheve10p77) est mise à jour à chaque requête sur un site quand vous êtes loggé.
Dès que le visiteur ne passe plus, le fichiers session reste en place.
Logiquement, au bout de x temps et x visiteurs, vous avez énormément de fichiers 'session' dans le répertoire /tmp (ou: chez moi: /var/lib/php5).
Il faut une solution sinon, vous allez manquer d'inodes très rapidement.

Ceux qui ont un serveur dédié doivent connaitre ce petit script cron:
Code:
# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete
Le script "/usr/lib/php5/maxlifetime" va fouiller dans le php.ini pour le vaiable session.gc_maxlifetime que vous pouvez voir avec un
Code PHP:
 phpinfo();
?>
Donc, ce cron s'écute chaque 30 minutes pour déterminer:
SI le script "/usr/lib/php5/maxlifetime" existe et s'il est exécutable,
SI le /var/lib/php5 existe,
Cherche toutes les fichiers (non-répertoires) avec une age plus que maxlifetime secondes puis, si il le trouve, il l’efface.

Si ce script n'exécute pas, mon disque va se remplir, pas en volume des données, mais nombre des fichiers - et le compteur "inodes" va exploser == arrête système d'urgence.
Bonjour,

ceci n'est plus nécessaire en faite avec le php 5.4 ??

mkwipe
24/10/2013, 01h13
Citation Envoyé par Nowwhat
Yeah.
Pour le stocker dans une ..... base SQL ?
mfw, encore pire

Nowwhat
24/10/2013, 01h08
Yeah.
Pour le stocker dans une ..... base SQL ?
Les bases d'une mutu peuvent encaisser ça, le traitement des sessions ?

testeur115 ne fait que trouver une seuil important sur son chemin: lui qui lui amène vers la l'outil qui s'appelle: dédié.

Avec les Mutus, il ne faut pas pousser. Respecter des petites nombres.
"100" ou "1000", ça va. "100000", ça va pas - surtout quand il y x autre sur le même serveur avec les mêmes ambitions.
testeur115: arrête de prendre le bus, prend le volant.

mkwipe
24/10/2013, 00h49
Citation Envoyé par testeur115
Pour le moment j'utilise vite fait les sessions mais limités donc ptete entre 100 et 1000 par jour.
Mais je voudrais reprendre comme avant tout un système de sessions et la je passerai à 100000 sessions par jour. Donc je voulais savoir si dans le /tmp par defaut ça passera bien, si mes sessions ne seront pas supprimé prématurément ?
à un moment il faut arrêter de stocker les sessions dans des fichiers :3

papacoolombo
07/10/2013, 12h45
hello,
me demande si vous avez eue la solution pour ne plus avoir donc ce problemes d'erreur de sessions,

ne croyez vous pas quand augmentant le session.gc_maxlifetime = 1440 ( par défaut ) que ca irais mieux et corrigerai legerement le problemes?

PPC

testeur115
21/09/2013, 17h26
Mais il y a plus de répartiteur de charge ? ou alors j'ai loupé un épisode lol, c'était pas justement le gros problème des mutualisés dernièrement ? l’arrêt du répartiteur de charges qui à fait que les gros sites se sont retrouvé sur des sous cluster bridé car n'étant plus répartis sur plusieurs serveurs ils faisaient buguer le serveur unique sur lequel ils sont. Non ?

Niloo
21/09/2013, 13h46
Il faut que le répartiteur de charge sache gérer les sessions afin d'envoyer le même visiteur toujours sur le même serveur afin que la session soit préservée.
Sauf si le dossier session est partagé entre tous les serveurs web du cluster.

testeur115
21/09/2013, 10h08
Ok car j'avais vu des sujets qui parlait de soucis de pertes de sessions mais a priori c'était lié au répartiteur de charge, qui n'est plus ?!

Niloo
21/09/2013, 09h51
Les sessions sont supprimées automatiquement quand session.gc_maxlifetime est atteint et pas avant sauf si session_destroy()

testeur115
21/09/2013, 08h39
Pour le moment j'utilise vite fait les sessions mais limités donc ptete entre 100 et 1000 par jour.
Mais je voudrais reprendre comme avant tout un système de sessions et la je passerai à 100000 sessions par jour. Donc je voulais savoir si dans le /tmp par defaut ça passera bien, si mes sessions ne seront pas supprimé prématurément ?

Nowwhat
20/09/2013, 23h25
Citation Envoyé par testeur115
et donc ce cluster dans le repertoire /tmp est commun a tout le monde pour les sessions ? Ils nous limitent pas en nombres de sessions ? n'en supprime pas des un peu vieille si trop de nouvelles ?
Avant, on a pu exécuter un 'ls -al /tmp'** pour 'voir' ces fichiers - sans aucun autre droit.
Le résultat été hallucinant.
Des centaines des milliers des fichiers de sesson de tout le monde.
ON a aussi pu voir 'cat /etc/passwd' pour voir le nombre de logins == nombre de sites sur UN cluster.
Disons: on est nombreux
Mais ce répertoire est balayé et nettoyé, comme je dit plus haut.
Un site sur un Mutu qui possède des milliers des sessions à donc des milliers des connexion (dans l'espace temps de session.gc_maxlifetime).

Avant d'arriver là, il faut dire que t'auras vraiment un très gros site, genre reuducommerce.fr et ta place n'est pas sur un Mutu.

Si tu dépasse de large avec ton site sur un cluster, OVH t'appel pour de dire:
€ (go dédié) ou go (ailleurs) [ou go Mutu-VPS-spécial-en-beta].

** me rappel plus exactement l'endroit, mais osef.

testeur115
20/09/2013, 21h53
et donc ce cluster dans le repertoire /tmp est commun a tout le monde pour les sessions ? Ils nous limitent pas en nombres de sessions ? n'en supprime pas des un peu vieille si trop de nouvelles ?

Nowwhat
20/09/2013, 16h39
Citation Envoyé par testeur115
non mais dans un dossier session au meme niveau que www
Il existe un thread sur ce forum (coté Mutu, je pense) ou on discute ce sujet.
Conclusion: faut pas faire ça.
Le filer est optimalisé pour:
Lecture des fichiers par un 'serveur web', le 'cluster'.
Ecriture/lecture par le serveur qui s'occupe de notre accès FTP - sachant que cet accès est quand même rare.
Le serveur web est pénalisé quand il doit écrire sur le filer ou est stocké notre hébergement.

Or, sur des gros sites avec des centaines des sessions en cours, l'écriture et mise à jour permanente des ces fichiers de sessions peut devenir très pénalisent en temps.

Donc: oui, sur un cluster, le répertoire /tmp (non - accessible pour nous, mais accessible pour le serveur web) est utilisé pour stocker nos fichiers des sessions.

Il faut savoir qu'un fichier session (typiquement nommé sess_0tjoubtttd9k2i2enheve10p77) est mise à jour à chaque requête sur un site quand vous êtes loggé.
Dès que le visiteur ne passe plus, le fichiers session reste en place.
Logiquement, au bout de x temps et x visiteurs, vous avez énormément de fichiers 'session' dans le répertoire /tmp (ou: chez moi: /var/lib/php5).
Il faut une solution sinon, vous allez manquer d'inodes très rapidement.

Ceux qui ont un serveur dédié doivent connaitre ce petit script cron:
Code:
# Look for and purge old sessions every 30 minutes
09,39 *     * * *     root   [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete
Le script "/usr/lib/php5/maxlifetime" va fouiller dans le php.ini pour le vaiable session.gc_maxlifetime que vous pouvez voir avec un
Code PHP:
 phpinfo();
?>
Donc, ce cron s'écute chaque 30 minutes pour déterminer:
SI le script "/usr/lib/php5/maxlifetime" existe et s'il est exécutable,
SI le /var/lib/php5 existe,
Cherche toutes les fichiers (non-répertoires) avec une age plus que maxlifetime secondes puis, si il le trouve, il l’efface.

Si ce script n'exécute pas, mon disque va se remplir, pas en volume des données, mais nombre des fichiers - et le compteur "inodes" va exploser == arrête système d'urgence.

Niloo
20/09/2013, 16h03
Si j'arrive à transférer un script PHP je pourrais alors lire ce dossier suivant comment est configuré open_basedir.

Pourquoi tu veux absolument toucher à ce paramètre ?
Cela ne fonctionne pas avec la valeur par défaut ?

testeur115
20/09/2013, 15h53
non mais dans un dossier session au meme niveau que www

Niloo
20/09/2013, 15h44
Il ne faut surtout pas que le dossier de session soit accessible via un navigateur, cela permettrait le vol de session.

testeur115
20/09/2013, 15h32
loll oui ça je sais.. je demande s'il faut mieu laissé la valeur par défaut ou mettre un dossier session directement sur son hébergement ?

Niloo
20/09/2013, 15h30
Pour connaître la valeur par défaut :

testeur115
20/09/2013, 13h46
Donc qui a des infos ?

testeur115
19/09/2013, 17h06
Bah justement c'est chez OVH que je demande

Gaston_Phone
19/09/2013, 17h02
Chez OVH, je ne sais pas. C'est OVH qui gère.
Sur mon PC, les valeurs par défaut me permettent de ne rien retoucher.

testeur115
19/09/2013, 16h59
ok mais au niveau de la valeur par défaut, les sessions sont enregistré ou ? un endroit comment à tout le monde ? Ca doit etre le bazar lol, non ?
Les sessions sont illimités ou pas au faite ?

Gaston_Phone
19/09/2013, 16h45
Personnellement je laisse les valeurs par défaut.

testeur115
19/09/2013, 16h35
concrètement il faut mieux mettre quoi maintenant laisser la valeur par défaut ou mettre un dossier session directement sur son hébergement ?

grddam
07/05/2004, 19h46
pour ma part, je mets cela :

session_save_path($DOCUMENT_ROOT."/../sessions");

c'est à dire un répertoire 'sessions' au même niveau que 'www'

VarioFlux
07/05/2004, 12h25
Bonjour,

Quelle valeur doit-on mettre dans le

ini_set('session.save_path','????????');

chez OVH ?

Merci