Il semble que mon cms yacs soit assez gourmant en espace disque [Integrated]

Owner

Bernard Paques

Progress

Workflow

Support request

Status

Solution has been fully integrated

Submission on Jul. 15 2011 by Thierry Nuttens
Analyzis on Jul. 24 2011
Action on Jul. 30 2011 by Bernard Paques
Finalization on Aug. 7 2011 by Bernard Paques

Voici le message d'n modératireur de tuxfamily:

"-Est-ce que par hasard ton site ne stockerait pas un peu beaucoup de données dans

les sessions PHP par hasard ? Parce qu'en moyenne, ça fait presque 250 Kio

de données par session là..." Ce soir mon quota était de nouveau atteind

Quelqu'un aurai-til une idée comment limiter le stockage de donné. Sachant que par ex, je nai pas encore activé la possibité d'uploader des fichiers

Merci d'avance

Thierry Nuttens	on Aug. 10 2011 Salut Bernard " A quand un guide d'installation de yacs sous nutyx, sur le modèle de ce qui a été fait pour Debian ? " C'est sur ma todo list, mais avant ya encore quelques tits détails à améliorer. bien à toi Thierry Bernard Paques - on Aug. 10 2011 Thierry : tiens moi au courant, si tu as besoin d'aide tu sais où me trouver ...
Bernard Paques	on Aug. 7 2011 La solution a été intégrée
Bernard Paques	on Aug. 7 2011 Bernard Paques est le nouveau propriétaire Une solution est disponible
Bernard Paques	on Aug. 7 2011 Thierry, merci du feed-back, c'est cool. Et j'ai été faire un tour sur nutyx.org, c'est très cool aussi. Bravo et merci d'utiliser yacs pour propulser ce site. A quand un guide d'installation de yacs sous nutyx, sur le modèle de ce qui a été fait pour Debian ?
Thierry Nuttens	on Aug. 5 2011 Installé depuis 5 jours sur le système de test, rien à signaler. Aucune perte de performance, je l'ai installé sur le site nutyx.org Encore merci à vous tous pour votre professionnalisme A bientôt Thierry
Alexis Raimbault	on Aug. 4 2011 Hello, Content de voir qu'une solution s'est dégagée ! Alexis Raimbault webmaster free-lance Bernard Paques - on Aug. 4 2011 Alexis : déjà de retour ? Je sais que le support de yacs te manque, mais quand même ...
Thierry Nuttens	on Aug. 2 2011 Vraiment un tout tout grand merci à vous tous Bernard, Xavier, Alexis pour votre excellent support. J'ai appliqué le patch sur mon server de test. les sessions sont tombé à: Correction: 43 Octets et une session avec utilisateur logué: 402 Octets. Je note également qu'avec ce patch, les sessions anciennes disparaissent alors que session.gc_probability = 0 ce qui n'était pas le cas auparavent. Je laisse un peu tourner sur l'înstall de test ensuite, je l'installe chez tuxfamily Bien à vous. Bien à vous Bernard Paques - on Aug. 2 2011 Thierry : voilà un premier résultat encourageant. Pas d'impact au niveau des performances vu de l'internaute ?
Xavier Guerrin	on Jul. 30 2011 Bonsoir Bernard, Merci pour cette correction -- je laisse le soin à Thierry de la mettre en place sur son CMS ; je pense que ce sera efficace en termes d'exploitabilité puisque tu as toi-même constaté le changement de taille des fichiers de sessions. En termes de performances : je pense qu'on a là un gain pour les archis orientées production[1] avec un minimum d'utilisateurs. Après, pour un seul utilisateur, sur un système dépourvu de cache d'opcode[2], je veux bien croire que la lecture d'un seul fichier avec un parsing simple[3] soit plus rapide que l'include/parsing de plusieurs fichiers PHP. Quant à la réécriture de la session, elle peut également avoir un coût nul dans certaines configurations comme par exemple l'utilisation d'un tmpfs pour le dossier des sessions. Il est de fait assez difficile d'écrire un code simple qui soit performant dans tous les cas de figure [1] terme sans doute mal choisi pour dire : écritures beaucoup plus couteuses que les parsings PHP. [2] APC, eaccelerator [3] le format lu par unserialize() est bien plus simple qu'un parsing PHP Bernard Paques - on Jul. 31 2011 Xavier, sur yacs.fr, c'est xcache qui a été installé pour le cache d'opcode PHP, et ça marche pas mal. J'attache ci-dessous le guide d'installation de yacs sur Linux Debian, qui a servi de référence pour yacs.fr comme pour les autres sites que je gère. N'hésite pas à me faire part de tes remarques le cas échéant. Et si ce guide pouvait être adapté à une autre distribution Unix, j'en serais très content, bien sûr ... 20110707 installation de yacs sous Linux Debian.pdf
Bernard Paques	on Jul. 30 2011 Et puis, aussi, pardon d'avoir pris du temps pour lire tous ces messages et pour traiter le problème, j'ai vraiment déconnecté d'Internet pendant ce temps de vacances. Retour officiel au bureau prévu le 2 août
Bernard Paques	on Jul. 30 2011 Voici donc un patch à appliquer pour ranger les chaînes de traduction dans `$context` au lieu de `$_SESSION`, ainsi que les `.mo.php` correspondants. Sur ma machine de développement, les fichiers de session sont passés à 4 koctets environ ... Merci d'appliquer le patch, et de confirmer ici-même l'effet observé. 20110730 patch i18n.tgz
Bernard Paques	on Jul. 30 2011 Xavier, un grand merci pour avoir pris le temps de critiquer l'usage des fichiers de session pour le rangement des chaînes de traduction. Je sens qu'il y a, derrière les arguments présentés, une vraie expérience, précieuse, de l'administration optimale de système web. Pour répondre à l'un des questions posées, l'idée d'utiliser les fichiers de session a été validée par un benchmark-maison montrant de meilleurs temps de réponse que dans la configuration précédente, qui consistait à charger directement les .mo.php (statiques). Mais bien évidemment, les résultats de test à toute petite échelle ne sauraient être transposés à des configurations réelles, et j'accepte totalement la réalité des problèmes rencontrés par Thierry. Comment faire face à ces problèmes ? Et bien, sur la base des conseils avisés de Xavier, en revenant au chargement direct des fichiers de traduction, pour vérifier que cela réduit la taille des fichiers de session et que le cache disque fait effectivement son boulot sur les fichiers statiques. Je vais préparer un patch à cet effet, avec une nouvelle version de `i18n/i18n.php` et une mise à jour des `.mo.php`, qui sera posté ici-même. Thierry et Xavier pourront alors nous dire si ce code donne de meilleurs résultats, avant généralisation dans le trunk principal de yacs sur GitHub.
Xavier Guerrin	on Jul. 24 2011 Bonsoir Alexis, Thierry y fait état d'une création de session par minute au moins, ce qui est anormal. Je n'ai pas regardé en détail dans quels cas Yacs choisit d'ouvrir une session, je n'ai donc pas d'avis sur la question. Après, ayant déjà vu des CMS créer une session par visiteur anonyme, ou plus simplement des sites avec plus de trafic, je ne suis pas choqué par ce nombre. Je te laisse investiguer avec Thierry sur l'optimisation de sa configuration sur ce point-là, mais ce n'est pas un point choquant pour moi. je copie également ici une explication de Bernard (developpeur à l'origine de Yacs) sur la copie des fichiers de trad vers $_session Analysons cela... Revenons à l'origine de cette conception pour bien la comprendre. Il est assez stupide de chercher, à chaque requête web, quelles sont les chaînes de traduction à utiliser et à charger les fichiers correspondants un à un. Effectivement, la plupart des optimisations consistent à minimiser les traitements et le nombre d'accès disques ou d'accès aux filesystems, souvent au profit d'accès à la mémoire virtuelle, qu'on souhaitera bien entendu sur la RAM pour un gain de performance notable. Jusque là, ça va donc. Au lieu de cela, yacs place ces chaînes en cache, avec les autres données de session, Loupé. Les données de session ne relèvent pas d'un quelconque cache. Par défaut, et telles qu'elles sont utilisées sur Yacs, elles sont stockées dans des fichiers, qui sont régulièrement (si ce n'est systématiquement, à vérifier) réécrits par les scripts PHP pour y stocker les dernières données de session. On pourrait aussi parler de l'impact du verrou que chaque script essayer de poser entre le session_start() et le session_write_close(), mais je ne pense pas que ce point précis impacte plus que ça dans le cadre de Yacs. ce qui permet de bénéficier des mécanismes de chargement super optimisés de PHP à chaque requête. Puis-je me permettre de demander quels sont ces "mécanismes de chargement super optimisés" (avec nom + référence vers un bout de documentation bien entendu) ? Aux dernières nouvelles, la seule optimisation dont PHP dispose pour charger les fichiers de session rapidement est le cache disque du kernel. Et ce cache disque travaille pour tous les fichiers sans discrimination, c-à-d qu'il sera mieux utilisé à mettre en cache une fois les fichiers .mo.php de référence plutôt que de gérer les lectures/écritures vers les n fichiers de sessions, n étant le nombre d'utilisateurs connectés simultanément. Le résultat, c'est de meilleures performances vues de l'utilisateur final, et moins de consommation CPU pour gérer les traductions. Non. Le résultat, c'est que les scripts PHP de Yacs doivent sérialiser, écrire, relire et désérialiser régulièrement ~200 Kio de données et ce pour chaque utilisateur, alors qu'ils pourraient simplement lire quelques fichiers .mo.php qui ne changent jamais et qui sont fréquemment accédés (donc solidement ancrés dans le cache disque). Oh, bien sûr, il reste possible de stocker le langage choisi en session plutôt que de le recalculer à partir des en-têtes Accept-Language, des preférences utilisateur et des traductions disponibles. De plus, de nos jours, pas mal d'installations LAMP incluent des cache d'opcode comme APC ou eaccelerator, qui offriront à PHP la possibilité d'accéder directement à la version parsée de ces fichiers (opcode) via des accès mémoires (à noter que dans le cas particulier de TuxFamily, ce cache est également sur disque, mais là encore, le cache disque joue son rôle). A contrario, non seulement l'écriture de la session implique des accès disques, mais en plus dans pas mal d'architectures ces accès disques se font sur des partages distants (chez TuxFamily, par exemple, c'est du NFS), ce qui alourdit le coût des écritures. En résumé : vous avez remplacé quelques lectures innocentes et super faciles à mettre en cache par une coûteuse écriture sur disque. Comme toujours en matière de performances, il y a un prix à payer qui est, ici, un peu de mémoire pour chaque session. Est-ce vraiment un problème, lorsque le prix de l'espace disque s'effondre chaque jour un peu plus ? L'effondrement du prix de l'espace disque est à relativiser en tenant compte du prix qu'il faut toujours payer pour avoir de bonnes performances pour un nombre élevé de lectures simultanées (plusieurs petits disques plutôt qu'un seul gros). Quant aux écritures sur disque, elles ont toujours représentées l'ennemi #1 des performances (ou #2 juste derrière "faire n'importe quoi sur le réseau"). Bref, cette conception semble assez peu défendable, et Thierry en fait aujourd'hui les frais. Y a-t-il eu des benchmarks pour comparer les deux approches ? Cordialement, Xavier G. Équipe TuxFamily Alexis Raimbault - on Jul. 24 2011 Xavier Guerrin : merci pour cette analyse détaillée. Attendons le retour de Bernard pour les réponses... Alexis Raimbault webmaster free-lance
Alexis Raimbault	on Jul. 24 2011 merci, à priori r.a.s de ce côté Alexis Raimbault webmaster free-lance
Thierry Nuttens	on Jul. 24 2011 En attendant que je restaure yacs http://nutyx.org/php
Alexis Raimbault	on Jul. 24 2011 merci Xavier pour cette intervention. le lien vers le rapport de bug de Thierry est Les sessions ne sont jamais supprimées Thierry y fait état d'une création de session par minute au moins, ce qui est anormal. je copie également ici une explication de Bernard (developpeur à l'origine de Yacs) sur la copie des fichiers de trad vers $_session " Revenons à l'origine de cette conception pour bien la comprendre. Il est assez stupide de chercher, à chaque requête web, quelles sont les chaînes de traduction à utiliser et à charger les fichiers correspondants un à un. Au lieu de cela, yacs place ces chaînes en cache, avec les autres données de session, ce qui permet de bénéficier des mécanismes de chargement super optimisés de PHP à chaque requête. Le résultat, c'est de meilleures performances vues de l'utilisateur final, et moins de consommation CPU pour gérer les traductions. Comme toujours en matière de performances, il y a un prix à payer qui est, ici, un peu de mémoire pour chaque session. Est-ce vraiment un problème, lorsque le prix de l'espace disque s'effondre chaque jour un peu plus ? " Thierry, peux-tu nous faire une vue d'écran de phpinfo() ? (/control/info.php) Alexis Raimbault webmaster free-lance
Thierry Nuttens	on Jul. 24 2011 Merci Xavier, pour ton intervention entre temps j'ai fais un rapport de bug. Bien à toi Thierry
Xavier Guerrin	on Jul. 24 2011 Bonjour, Je suis Xavier, de l'équipe TuxFamily. Je me permets d'intervenir sur ce thread car il semblerait qu'il y ait quelques problèmes de communication (beaucoup d'infos transmises mais éludées ou non publiées ici). Je vais également me permettre de citer ici des extraits de mails entre Thierry et TuxFamily, ce qui ne devrait pas poser de problèmes à Thierry dans la mesure où cela contribuera à résoudre ses soucis. Résumé des événements : Le 14/07 à 22:02, Thierry nous a contacté pour nous signaler qu'il ne comprenait pas son quota. Il faut savoir que chez TuxFamily, le quota d'un projet est en fait un "group quota" standard appliqué à un filesystem regroupant les données du site web, un dump des bases de données et les sessions PHP, lesquelles ne sont pas mises en valeur dans l'arborescence virtuelle mise à disposition des hébergés. De plus, ce quota est appliqué en temps réel mais son report dans notre "panel" (pour consutlation par l'hébergé) ne se produit que toutes les heures. Il est donc extrêmement difficile pour un hébergé d'affirmer qu'une modification donnée (exemple : purge du cache interne du CMS) a bien un impact sur le quota. L'équipe d'administration a bien entendu plus de facilités pour faire un état des lieux Le 14/07 à 23:04, j'ai fourni une brève explication de nos quotas à Thierry avant de lui fournir les informations suivantes, qui correspondent donc à une mesure effective des sessions générées par le site de Thierry: Donc, si je vais y faire un petit tour... # find -group 25778 -printf "%s\n" \| perl -ne'$t+=$_;END{printf("%.2fM for %d files\n",$t/1048576,$.)}' 78.46M for 326 files Je crois que ceci explique la différence de quota que tu constates -- est-ce que par hasard ton site ne stockerait pas un peu beaucoup de données dans les sessions PHP par hasard ? Parce qu'en moyenne, ça fait presque 250 Kio de données par session là... Je me permets une traduction : nous avons bel et bien 326 fichiers de session (raisonnable) prenant un total de 78.46 Mio (non négligeable par rapport au quota de Thierry) soit une moyenne de 250 Kio de session (pas raisonnable, la moyenne pour la plupart des applications PHP tourne entre 1 et 10 Kio). Le 15/07 à 20:43, Thierry nous signale que son quota est de nouveau atteint. Le 15/07 à 21:53, ma réponse inclut une nouvelle mesure, effectuée de la même manière que la précédente, et résumant les sessions du site de Thierry à : "110.05M for 595 files". J'en profite pour signaler que nos sessions sont chiffrées par SuHosin et que je ne peux donc pas lire directement leur contenu par simple ouverture de fichier. De même, nos sessions sont bien cyclées et aucun fichier de session pour Thierry n'était déraisonnablement vieux (une journée maxi). Le 16/07 à 23:44, Thierry nous signale l'existence de ce thread. Le 17/07/2011 à 15:57, je m'offre une courte plongée dans le code de Yacs et transmet mes premières conclusions par mail à Thierry, comptant sur lui pour les relayer efficacement. Je publie ici ma prose : Un rapide grep des affectations dans $_SESSION dans le code de yacs montre, sauf erreur de ma part, que les sessions PHP[0] sont utilisées pour stocker... les traductions dans la langue de l'utilisateur courant (cf dossier htdocs/i18n). Cela pourrait expliquer pourquoi les sessions prennent tant de place : le moindre utilisateur connecté[1] va créer une copie supplémentaire des données de localisation dans un dossier dédié aux sessions[2]. Et à raison de 600 Kio par langue, pour le peu que tout ne soit pas chargé et que la sérialisation apporte un peu de compression par rapport aux fichiers *.mo.php originaux, ça colle à ce qu'on constate. Il s'agirait donc d'une erreur de conception du côté de yacs. [0] qui sont donc régulièrement lues, désérialisées, parcourues, resérialisées et réécrites sur disque. Bonjour les performances. [1] plus exactement : disposant d'une session PHP [2] cf paramètre PHP session.save_path -- chez nous, ça vaut /data/web/tmp sur nos serveurs web, et c'est compté dans le quota. Je crois que les informations sont assez exhaustives : mesures fiables + proposition de piste pour trouver la source du problème. Ce qui nous amène à la question suivante : c'est quoi ce trip des traductions en session :') ? Cordialement, Xavier, Équipe TuxFamily
Alexis Raimbault	on Jul. 24 2011 Thierry, tant que tu ne pourras visusaliser toi-même ton /data/web/tmp on va tatonner. Il faut visualiser ce répertoire pour valider si c'est effectivement les fichiers de sessions qui bouffent les 150Mo d'hébergement. Car la cause est peut-être autre chose... Alexis Raimbault webmaster free-lance
Thierry Nuttens	on Jul. 23 2011 Le problème est effectif et reproductible
Alexis Raimbault	on Jul. 17 2011 Pas reçu de mail... Alexis Raimbault webmaster free-lance
Thierry Nuttens	on Jul. 17 2011 @alexis, Je t'ai envoyé une réponse de tuxfamily par email avec peut-être quelques pistes Bien à toi Thierry
Alexis Raimbault	on Jul. 17 2011 Il te faut un client FTP qui sache calculer récursivement la taille des répertoires et puis chercher ce qui consomme de l'espace disque. Compare avec une archive yacs toute fraîche décompressée en local. Alexis Raimbault webmaster free-lance
Thierry Nuttens	on Jul. 16 2011 " L'installation de yacs fait 13Mo. Tu sais pourquoi tu as 38 " Il y a aussi un outil suivi de bug mantis qui prends 12 Mb d'espace
J.Juraver	on Jul. 16 2011 Je n'ai jamais vu une installation yacs peser aussi lourd si on compte ni la BDD ni le stockage brut de fichier (ou yacs utilisé comme une GED). Soit le chiffre est faux et ton quota consommé est irréel, soit tu as des fichiers qui traînent quelque part sur ton disque, assez lourds, tels que multimedias ou fichiers de sauvegarde FTP. Ca arrive souvent quand on a migré un site d'un CMS à un autre, on a stocké des backup par FTP, puis on les retrouve plus... Je ne m'attarde pas, j'ai mon yacs en double file... Yacs on my blog \| Suivez le blog Yacs \| Yacs Showroom \| Plugin Firefox de recherche dans Yetanoz \|
Thierry Nuttens	on Jul. 16 2011 J'avoue que là je suis un peu pommé. J'ai tout essayé et mon site consomme ... 147 Mb et mon quota sur le serveur web est de 150 Mb. Ils me fournissent un espace de téléchargement, d'ailleurs tous les copies d'écrans sont sur cette espace de téléchargement et non sur le serveur web. L'espace occupé par la base de données n'est pas pris en compte par mon quota. .. Bref en gros, je crie "A l'aide" Merci de votre aide Thierry
J.Juraver	on Jul. 16 2011 Prends note sue si tu migres vers OVH un jour, ils t'offre un analyseur de performance de tes scripts. La table "versions" grandit très vite effectivement, d'autant plus si tu as de nombreuses pages que tu modifies souvent. Tu peux directement vider la table "versions" depuis phpmyadmin ou autre (vider, pas supprimer). Je ne m'attarde pas, j'ai mon yacs en double file... Yacs on my blog \| Suivez le blog Yacs \| Yacs Showroom \| Plugin Firefox de recherche dans Yetanoz \|
Alexis Raimbault	on Jul. 16 2011 L'installation de yacs fait 13Mo. Tu sais pourquoi tu as 38 ? la base MySQL est comptée ? Sinon dans le panneau de controle>>systeme>>purge tu as une commande pour vider le cache. depuis cette page tu peux aussi supprimer les .bak et les fichier temporaire de mise à jour (si tu en a déjà fait une) Note que le cache concerne surtout des enregistrements dans la base de données et non pas des fichiers. les fichiers de cache sont dans /temporary. Regarde ici sur yacs.fr/control, dans l'onglet aperçu tu as une vue de toutes les tables de la base. la table cache ne compte que 70 enregistrements. La taille totale de la base est 190Mo (en bas du tableau), et le site contient beaucoup de pages. le plus souvent, la table qui gonfle est "version". Une commande de purge à été recement ajoutée. Pour finir, il serait envisageable de déclencher automatiquement la purge via le système de hook (cron job) Alexis Raimbault webmaster free-lance
Thierry Nuttens	on Jul. 15 2011 J'ai pu allé dans: Panneau de contrôle->Paramètres système->Recalculer tous les éléments de pages. activé Mon espace disque qui était à 151 Mb est du coup retombé à 38 Mb. Je suis sauvé Peut-être une possibilitée serai de pouvoir spécifier une taille de cache maximum. Honnêtement, j'ignore si c'est possible. Bien à vous
Thierry Nuttens	on Jul. 15 2011 Une solution immédiate a été fournie
Thierry Nuttens	on Jul. 15 2011 Page has been created