Piwigo.org

nicolas · 2006-01-10 21:28:41

z0rglub a écrit:
Je suis d'accord avec toi que j'ai réinventé la roue. C'était à une époque où la roue n'était pas disponible partout et là où elle était disponible, elle était mal supportée (mal fixée sur son essieu).

Je te trouve un chouillas de mauvaise foi. :-) Le mécanisme des sessions existe depuis php3 avec la phplib et nativement depuis les toutes premières versions de php4 et donc depuis 2000. En revanche je t'accorde que le mécanisme n'était peut-être pas aussi rodé qu'aujourd'hui.

Mon seul et unique point de mécontentement, c'est le backend. Je ne maîtrise pas encore très bien le mécanisme standard des sessions, mais j'ai bien l'impression qu'on est obligé de stocker les sessions dans des fichiers. Le mécanisme PWG stocke les sessions dans la table #sessions. Les fichiers, c'est bien, mais ça amène systématiquement des problèmes (de présence, de droits d'écriture, de fonctionnement sur tel hébergeur et pas tel autre...).

Hônnetement je pense que c'est de mieux en mieux gérer. Je pense à free en particulier où c'est écrit en clair dans la faq qu'il faut créer un répertoire sessions à la base de l'espace web. Il n'y a pas de problème particulier pour les droits d'écriture.
On peut prévoir dans l'installation ce type de problématique suivant les hébergeurs.

Je base mon argumentaire sur l'évolution qu'à connu Dotclear. En effet depuis la version 1.2.1, les sessions sont stockées en base de données. Je n'ai pas suffisamment étudié le code pour dire dans quelle mesure Dotclear continue à utiliser le mécanisme standard.

J'ai parcourru, trituré, hacké le code de dotclear mais je dois avouer que je ne comprends pas très bien pourquoi dotclear utilise son propre mécanisme de sessions. Je ne pense pas que ce ne soit qu'une idée sur un coup de tête d'Olivier. Il doit y avoir des raisons objectives derrière. J'investiguerais.

Ma thèse, c'est que je ne souhaite pas qu'on fasse un retour arrière dans 6 mois, alors que tout marche parfaitement aujourd'hui. Je suis cependant OK sur le principe si :
- tu t'en occupes :-) parce que ce n'est pas le genre de modification sur lesquelles je souhaite passer du temps
- tu arrives à faire un résumé du pourquoi du comment Dotclear a changé sa gestion des sessions en 1.2.1

Je suis aussi d'accord sur le retour en arrière.
Il va de soi que j'ai envie de m'en occuper. Je pense qu'une branche particulière simpose. Qu'en penses-tu ?
De toute façon j'expliquerais en détail le fonctionnement.

nicolas · 2006-01-10 21:34:25

z0rglub a écrit:
Pas si sûr que le goulet soit au niveau de la récupération, il est aussi au niveau du traitement des données récupérées. Tu cites l'exemple de l'arbre des catégories, alors parlons-en :-).

Si pour la branche 1.5, la table #user_forbidden s'est vue renommée en #user_cache, c'est pour pouvoir accueillir d'autre données que la liste des catégories interdites. Je pensais trivialement au nombre total de photos accessibles. Ajouter une colonne avec l'arborescence des catégories sous forme d'un tableau sérialisé, ce serait une excellente idée.

Mettre ce tableau dans la session, je suis contre. A quel moment ce tableau doit il être reconstruit ? A chaque fois que l'administrateur opère dans la zone administration. C'est pour cela que dans admin.php, il y a une purge de #user_cache. Complètement inutile de reconstruire ces données à chaque session, et pire, dommage de supprimer toutes les sessions parce qu'elles stockent des données obsoletes si l'administrateur opère alors que des utilisateurs naviguent dans la galerie.

Je n'ai pas fini mes réflexions mais je pense néanmoins que l'on doit pouvoir diminuer le nombre de requête et mettre certaines infos en sessions. A creuser.

VDigital · 2006-01-10 22:17:36

z0rglub a écrit:
Si pour la branche 1.5, la table #user_forbidden s'est vue renommée en #user_cache, c'est pour pouvoir accueillir d'autre données que la liste des catégories interdites. Je pensais trivialement au nombre total de photos accessibles. Ajouter une colonne avec l'arborescence des catégories sous forme d'un tableau sérialisé, ce serait une excellente idée.

Mettre ce tableau dans la session, je suis contre. A quel moment ce tableau doit il être reconstruit ? A chaque fois que l'administrateur opère dans la zone administration. C'est pour cela que dans admin.php, il y a une purge de #user_cache. Complètement inutile de reconstruire ces données à chaque session, et pire, dommage de supprimer toutes les sessions parce qu'elles stockent des données obsoletes si l'administrateur opère alors que des utilisateurs naviguent dans la galerie.

Excusez-moi, mais pour une fois...
A quel moment ce tableau doit il être reconstruit ?...
Pour moi, ce tableau ne doit pas exister du tout... Imaginez que vimages débarque avec disons 1700 membres inscrits.
Le serveur où se trouve PWG passe son temps à faire quoi?

Je ferme la parenthèse, votre discussion est passionnante, on avance. Je me la referme. Merci.

plg · 2006-01-10 22:42:32

nicolas a écrit:
z0rglub a écrit:
Je suis d'accord avec toi que j'ai réinventé la roue. C'était à une époque où la roue n'était pas disponible partout et là où elle était disponible, elle était mal supportée (mal fixée sur son essieu).
Je te trouve un chouillas de mauvaise foi. :-) Le mécanisme des sessions existe depuis php3 avec la phplib et nativement depuis les toutes premières versions de php4 et donc depuis 2000. En revanche je t'accorde que le mécanisme n'était peut-être pas aussi rodé qu'aujourd'hui.

Diantre, je suis démasqué. Je te l'accorde, j'ai réinventé la roue parce que je ne connaissais pas les sessions PHP au début de l'aventure PWG.

nicloas a écrit:
Mon seul et unique point de mécontentement, c'est le backend. [...].
Hônnetement je pense que c'est de mieux en mieux gérer. Je pense à free en particulier où c'est écrit en clair dans la faq qu'il faut créer un répertoire sessions à la base de l'espace web. Il n'y a pas de problème particulier pour les droits d'écriture.
On peut prévoir dans l'installation ce type de problématique suivant les hébergeurs.

C'est exactement ce que je souhaite éviter. C'est peut-être pour cela qu'Oliver (Meunier, le développeur principal de Dotclear) est passé au stockage en base de données.

nicolas a écrit:
J'ai parcourru, trituré, hacké le code de dotclear mais je dois avouer que je ne comprends pas très bien pourquoi dotclear utilise son propre mécanisme de sessions. Je ne pense pas que ce ne soit qu'une idée sur un coup de tête d'Olivier. Il doit y avoir des raisons objectives derrière. J'investiguerais.

... avant de commencer tout développement :-) En effet, je pense que c'est la bonne démarche.

nicolas a écrit:
Je pense qu'une branche particulière simpose. Qu'en penses-tu ?

Cela me semble inutile. Tu peux travailler sur la branche de dev. Cela n'est pas tellement impactant. La session ne sert pour le moment qu'à savoir à quel identifiant utilisateur on a affaire.

Ce qui serait bien par contre, ce serait de créer la demande d'évolution dans l'outil de suivi, ce qui nous permettra d'en suivre l'avancée (tu gères cela tout seul, et les autres regarderont).

plg · 2006-01-10 22:48:22

VDigital a écrit:
A quel moment ce tableau doit il être reconstruit ?...
Pour moi, ce tableau ne doit pas exister du tout... Imaginez que vimages débarque avec disons 1700 membres inscrits.
Le serveur où se trouve PWG passe son temps à faire quoi?

La table #user_cache, c'est l'avancée majeure en terme de performances. Elle est arrivée en 1.4. Toute l'astuce, c'est que les données en cache ne sont jamais toutes recalculées en même temps. Le cache d'un utilisateur n'est recalculé que lorsque l'utilisateur visite une page et que son cache est obsolete. Les caches sont donc reconstruits un par un, ce qui est négligeable en terme de charge pour le serveur.

Je trouve que la solution trouvée est particulièrement bien (j'en suis fier on va dire). Je te remercie d'avoir posée la question, cela m'a donné l'occasion de l'expliquer :-)

VDigital · 2006-01-10 23:19:59

Je comprends bien et je me doutais de ta première réponse (on a l'habitude de se les faire comme au billard: bande-bande-bande et toc).
1700 visiteurs x 40000 photos = 68 000 000 d'entrées dans le cache.
Non, je n'ai rien dit ce ne sont pas des infos sur les photos que tu veux mettre dans le cache mais celles de catégories.
Ok, je n'ai rien dit. 8;-)
A la prochaine.

Eric: 1700 c'était une supposition.
Fais comme moi retire toi, on leur pourrit le topic.

nicolas · 2006-01-11 09:04:01

Je ne comprends mes post sont en doubles sur ce topic. J'en ai supprimé un et les deux ont été supprimés. Que se passe-t-il ? Est-ce lié au problème de base d'hier après-midi ?

volcom · 2006-01-11 11:03:12

excusez moi, je rouvre une parenthèse, je ne me suis jamais intéressé à cet aspect, mais que met on en cache dans cette fameuses table ? user_id, need_update, forbidden_categories , mais ça ne m'aide pas ..

nicolas · 2006-01-11 12:04:35

Concernant dotclear (pour la version 1.x; on ne peut évidemment pas savoir pour la version 2!), les sessions utilisent le mécanisme standard php mais en changer le moyen de stockage en utilisant la fonction session_set_save_handler() pour utiliser une base de données.
Je suis rassuré de voir que je ne suis pas le seul à ne pas vouloir réinventer la roue et vouloir utiliser le mécanisme standard.
On peut aloir à souhait soit utiliser le stockage par fichier ou en base. Je suis d'avis d'offrir la possibilité de paramétrer cela dans le fichier de configuration en prenant comme paramètre par défaut le stockage en base. Si on veut utiliser le stockage dans des fichiers on n'utilisera pas la fonction session_set_save_handler() et ce sera transparent pour le reste du code.

plg · 2006-01-11 22:11:36

nicolas a écrit:
Concernant dotclear (pour la version 1.x; on ne peut évidemment pas savoir pour la version 2!), les sessions utilisent le mécanisme standard php mais en changer le moyen de stockage en utilisant la fonction session_set_save_handler() pour utiliser une base de données.

Merci pour l'analyse.

nicolas a écrit:
Je suis rassuré de voir que je ne suis pas le seul à ne pas vouloir réinventer la roue et vouloir utiliser le mécanisme standard.

:-) espèce de sarcastique, je sais bien que c'est toi qui a raison.

nicolas a écrit:
On peut aloir à souhait soit utiliser le stockage par fichier ou en base. Je suis d'avis d'offrir la possibilité de paramétrer cela dans le fichier de configuration en prenant comme paramètre par défaut le stockage en base. Si on veut utiliser le stockage dans des fichiers on n'utilisera pas la fonction session_set_save_handler() et ce sera transparent pour le reste du code.

Parfait. C'est un excellent compromis. J'ai hâte de voir ce que ça va donner.

Merci d'avoir créer la demande 261 pour nous faire partager l'avancée de ton travail.

VDigital · 2006-01-11 22:16:12

Dites donc: Est-ce que, pour éviter le problème de départ, cela ne vaudrait pas le coup de mettre un lien quelque part sur chaque page.

J'ai la flemme de chercher la variable alors j'ai écrit {url_de_la_page} sans ID= bien sûr.

Code:

<a href="mailto:?subject=A%20voir%20absoluement&body=Je%20viens%20de%20voir%20ça%20{url_de_la_page}">Ecrire à ...</a>

C'est peut-être débile de chez débile, mais si ça peut éviter des mails avec l'ID de l'admin...
(Tiens, si ça se trouve c'est déjà possible de le faire avec les pages ping-pong...)

plg · 2006-01-11 22:23:26

volcom a écrit:
excusez moi, je rouvre une parenthèse, je ne me suis jamais intéressé à cet aspect, mais que met on en cache dans cette fameuses table ? user_id, need_update, forbidden_categories , mais ça ne m'aide pas ..

Suite de la discussion sur le cache utilisateur dans le topic 5473

nicolas · 2006-01-12 20:17:32

z0rglub a écrit:
Merci pour l'analyse.

Pas de problème. J'expliquerais tout cela en détail sur le wiki une fois le boulot terminé!

z0rglub a écrit:
Parfait. C'est un excellent compromis. J'ai hâte de voir ce que ça va donner.

J'espère avoir quelque chose de fonctionnel la semaine prochaine si j'arrive à me dégager un peu de temps d'ici là!

nicolas · 2006-01-15 14:51:50

Je continue dans le même sujet pour vous tenir au courant de l'évolution. Je me suis un peu dispersé dans mes explications.
En y regardant de plus près tout à l'heure je me suis apperçu que cela allait être plus complexe (et pas plus compliqué!) que prévu. Cela va juste me prendre un peu plus de temps!
Les modifications que j'ai déjà faites:
- dans le fichier de configuration général (include/config_default.inc.php), dans la partie sessions j'ai ajouté:

Code:

$conf['session_use_cookies'] = 1;
$conf['session_use_only_cookies'] = 1;
$conf['session_use_trans_sid'] = 0;
$conf['session_name'] = 'pwg_id';
$conf['session_save_handler'] = 'db';

Les 3 premières variables configurent le fonctionnement des sessions: l'identifiant de session est stocké côté client dans un cookie et il ne transite pas dans l'url. La 4ème variable définit le nom de ce cookie. La 5ème permet de choisir le type de stockage des sessions côté serveur; par défaut on les stockera dans la base de données (db) mais on peut imaginer d'utiliser le comportement par défaut des sessions i.e stockées dans des fichiers.

J'ai d'autre part modifié le fichier include/functions_session.inc.php pour définir le stockage des sessions avec la fonction session_save_handler(). J'ai utiliser 6 fonctions que j'ai préfixées par pwg_session, à savoir pwg_session_open, pwg_session_close, pwg_session_read, pwg_session_write, pwg_session_destroy et pwg_session_gc.
L'utilisation du stockage en base va m'obliger à modifier la table sessions de la manière suivante;

Code:

/* table originelle: */
phpwebgallery_session {
  `id` varchar(255) binary NOT NULL default '',
  `user_id` smallint(5) NOT NULL default '0',
  `expiration` datetime NOT NULL default '0000-00-00 00:00:00',
  PRIMARY KEY  (`id`)
} TYPE=MyISAM;

/* nouvelle table: */
phpwebgallery_session {
  `id` varchar(255) binary NOT NULL default '',
  `data` text NOT NULL,
  `expiration` datetime NOT NULL default '0000-00-00 00:00:00',
  PRIMARY KEY  (`id`)
} TYPE=MyISAM;

Je vais maintenant m'attaquer à l'utilisation des sessions proprement dites ce qui représente le gros du boulot.

Si d'ores et déjà vous avez des questions ou remarques j'y répondrais avec plaisir.

p.s: aucune de ces modifications n'a été mise à jour dans le dépot puisque cela n'a un sens que dans son ensemble.

p.s: je reporterais toutes ces explications dans le wiki quand ce sera terminé.

plg · 2006-01-17 19:51:15

nicolas a écrit:
Je vais maintenant m'attaquer à l'utilisation des sessions proprement dites ce qui représente le gros du boulot.

Aujourd'hui, les sessions sont simplement utilisées pour être associées à un utilisateur, ensuite les données liées à l'utilisateur sont chargées dans $user. Je ne pense pas que l'impact soit si important, ou alors j'ai loupé quelque chose. Je considère que add_session_id, ça touche beaucoup de code, mais c'est simplissime à supprimer.

nicolas a écrit:
Si d'ores et déjà vous avez des questions ou remarques j'y répondrais avec plaisir.

Oui, une remarque : n'oublies pas mettre un commentaire au dessus de chaque paramètre de $conf dans include/config_default.inc.php à l'image des autres paramètres. Je ne sais pas si tu comptais le faire, mais l'extrait de code laisse supposer que non.

N'oublies pas non plus de supprimer le paramétrage obsolete lié aux anciennes sessions.

nicolas a écrit:
p.s: je reporterais toutes ces explications dans le wiki quand ce sera terminé.

Si tu veux, mais j'ai pour idée de réserver les spécifications du wiki pour les évolutions fonctionnelles, pas tellement pour les évolutions techniques. Enfin, si tu veux ajouter des explications dans le wiki, ce ne peut être que bénéfique.

Piwigo.org

Annonce

#31 2006-01-10 21:28:41

Re: Pas encore très sécuritaire PWG ???

z0rglub a écrit:

#32 2006-01-10 21:34:25

Re: Pas encore très sécuritaire PWG ???

z0rglub a écrit:

#33 2006-01-10 22:17:36

Re: Pas encore très sécuritaire PWG ???

z0rglub a écrit:

#34 2006-01-10 22:42:32

Re: Pas encore très sécuritaire PWG ???

nicolas a écrit:

z0rglub a écrit:

nicloas a écrit:

nicolas a écrit:

nicolas a écrit:

#35 2006-01-10 22:48:22

Re: Pas encore très sécuritaire PWG ???

VDigital a écrit:

#36 2006-01-10 23:19:59

Re: Pas encore très sécuritaire PWG ???

#37 2006-01-11 09:04:01

Re: Pas encore très sécuritaire PWG ???

#38 2006-01-11 11:03:12

Re: Pas encore très sécuritaire PWG ???

#39 2006-01-11 12:04:35

Re: Pas encore très sécuritaire PWG ???

#40 2006-01-11 22:11:36

Re: Pas encore très sécuritaire PWG ???

nicolas a écrit:

nicolas a écrit:

nicolas a écrit:

#41 2006-01-11 22:16:12

Re: Pas encore très sécuritaire PWG ???

Code:

#42 2006-01-11 22:23:26

Re: Pas encore très sécuritaire PWG ???

volcom a écrit:

#43 2006-01-12 20:17:32

Re: Pas encore très sécuritaire PWG ???

z0rglub a écrit:

z0rglub a écrit:

#44 2006-01-15 14:51:50

Re: Pas encore très sécuritaire PWG ???

Code:

Code:

#45 2006-01-17 19:51:15

Re: Pas encore très sécuritaire PWG ???

nicolas a écrit:

nicolas a écrit:

nicolas a écrit:

Pied de page des forums