Charge serveur PluXml ?

Bonjour à tous,
j'aimerai savoir si parmi vous il y en avait qui posséderait un blog PluXml avec un trafic conséquent (genre entre 5k et 10k visites par jours) et quel était la consommation en ressource serveur ?
J'avoue ne pas trop connaitre le XML, est-ce plus efficace qu'une base MySQL par exemple ?
Merci de vos retours.

Réponses

  • Bonjour, le faite que se soit en XML intervient peu il me semble. Ce qui change par rapport à une base mysql est le faite que dans PluXML tout est fichier, c'est à dire que les articles, pages, catégories, paramètres sont stocké dans des fichiers aux formats xml. Maintenant savoir si une base de données sera plus efficace que les fichiers, je dirais tout dépend de ton serveur. Si t'a la chance de posséder le tiens tu peux optimiser telle ou telle paramètres au niveau système. Si tu est sur un mutualisé ou gratuit c'est au bon vouloir que l'hébergeur, sachant que pour le denier cas le but est d'accueillir un max de personnes avec un minimum de ressources consommer.

    J'ai un string de l'array

  • AudiofeelineAudiofeeline Member
    juillet 2009 modifié
    Je pense qu'il serait intéressant d'avoir des retours à grande échelle parce que je pense que ça doit générer pas mal de hits, à chaque fois on fait appel à plusieurs fichiers, il y a un système de cache ?
  • StéphaneStéphane Member, Former PluXml Project Manager
    Bonjour Audiofeeline

    Pour faire simple, Pluxml se veut pour des petits sites (blog) avec un traffic raisonnable. Si ton site a une grosse fréquentation, il vaut mieux s'orienter faire un cms avec une architecture autour d'une base de données car cela sera beaucoup plus performant. Les accès d'entrée/sorties (lecture/écriture) sur des fichiers consomment de la cpu (qu'ils soient au format txt, xml, csv, etc...). Pour des grosses requêtes rien n'est plus performant qu'un SGDB (système de gestion de base de données) car c'est prévu pour. De plus il faut faire la distinction entre la gestion de données statiques et dynamiques. Si tu as un contenu qui change rarement, un système de fichier est intéressant (c'est pour cela que généralement les caches font appel à des fichiers). Si tu dois mettre à jour fréquemment des données au fil de l'eau, la base de données sera préférable.

    et pour ta question non pluxml n'a pas de cache.

    Stéphane

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • Je compte aussi utiliser Pluxml pour un site qui devrait avoir un gros traffic et j'hésite ... le contenu ne devrait pas changer souvent mais il y aurais pas mal de traffic et beaucoup d'accès simultannés. À suivre ;)
  • StéphaneStéphane Member, Former PluXml Project Manager
    Bonjour Alex7995

    Si tu choisis pluxml, cela serait bien de nous faire un retour sur les performances de ton site en fonction du nombre de visiteurs journaliers par exemple.

    Je rajoute par rapport à mon précédent post, que les performances de l'hébergeur jouent aussi un rôle très important.

    Stéphane

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • Le site du projet PluXml.org (basé sur des PluXml bien sûr...) est hébergé chez Gandi (1 part hébergement serveur virtuel sous Debian) avec une vingtaine d'autres sites (sous PluXml en majorité).
    Le serveur tient très bien la charge (0,3 en moyenne).
    J'ai installé récemment sur ce serveur un Dotclear et un Wordpress et rien qu'en me baladant sur ces sites, la charge est tout de suite montée à presque 1...
    C'est sûr que PluXml ne joue pas dans la même cour mais est tout de même beaucoup moins gourmand en ressources ! On peut dire que PluXml est Green ;)
  • Je réagit un peu après mais pour moi je ne doute pas sur la rapidité de PluXml mais le comportement de la bête avec un fort trafic (accès concurrents aux fichiers, un important volume de données, etc ...) ce qui peux poser problème ... Je pense pas que PluXml soit adapté pour des milliers de commentaires et des centaines d'articles ;) Il faudrait que PluXml puisse gérer un SGBDD :) Et pouvoir choisir à l'installation le modèle de stockage des données :) Après faudrait aussi voir si y peux pas être couplé à MemCached, car justement, allez sans arrêt pomper des les fichiers niveau I/O disque ... Pas top ...
  • @Alex7995 : PluXml n'a pas la réputation et la volonté de faire tourner des sites avec des milliers d'articles et de commentaires, pour ce faire Dotclear, Wordpress sont là pour ça avec un SGBD.
    Par contre, sur la toile, qu'avons nous à notre disposition pour des sites/blogs de petite ou moyenne envergure ? Pas grand chose peut être... PluXml est parti de ce constat !
    Un site d'une centaine d'article fonctionnera très bien avec bcp de traffic, avec 2000 articles ce sera plus dur.
    Je t'invite peut être à lire cet article => http://t37.net/concevoir-une-usine-i-gaz-est-plus-simple-quun-logiciel-qui-ne-fait-quune-seule-chose-simplement.html
  • Dans mon cas je prévois environ 3 articles par semaine ... Au minimum ... Donc je vais plutôt m'orienter vers un lourd WordPress ... Il faudrait qu'il y ai un juste milieu ... J'ai pensé à coder moi même mon propre "moteur" en utilisant un SGBDD et restant sur un truc rapide, optimisé, fiable et simple. J'ai commencé et je pense que je vais continuer, j'aurais en plus une flexibilité énorme et je connaitrais bien sur quoi je bosse :) Merci pour vos conseils
  • Bonsoir,

    Ayant vu ce site à plusieurs reprises dans mes referers (je suis l'auteur de l'article sur les usines à gaz sus mentionnées), et aimant, d'une manière générale, donner mon avis sur tout, surtout quand on en me le demande pas, j'ai 2-3 remarques à faire en passant.

    @Audiofeeline : je ne sais pas si PluXml dispose d'un système de cache statique (pas trouvé cette information, mais si c'est le cas, ce serait bien de le mettre en avant dans les features importantes), mais dans tout les cas, ton site risque de se retrouver avec de gros problèmes d'I/O
    – Si ton site a pas mal de commentaires, problèmes d'accès concurrentiels aux fichiers en écriture pour l'enregistrement des commentaires.
    – Si pas de cache, risque d'atteindre rapidement le maximum de descripteurs de fichiers ouverts en même temps, d'autant qu'il n'est jamais très élevé chez les hébergeurs mutualisés.

    @Alex7995 : Je pense perso que c'est une erreur. Autant faire son blog est top pour apprendre, autant en créer un à des buts de mise en production recouvre des enjeux – notamment de sécurité et de performances – qu'il ne faut pas prendre à la légère (XSS, SQL injections, CSRF...). Quand tu vois le nombre de vulnérabilités déclarées (ou non) dans des outils comme Wordpress ou Joomla alors qu'ils sont développés par des professionnels plutôt compétents (je ne dis pas que tu ne l'es pas), et audités avant release par un paquet de monde, je pense que le mieux est encore d'utiliser les outils à ta disposition, quitte à les tuner un peu selon tes besoins (et puis, pourquoi vouloir réinventer la roue ?).

    Mes 2 cents.
  • StéphaneStéphane Member, Former PluXml Project Manager
    Bonsoir fdv

    Merci pour ton témoignage et d'avoir pris le temps de le partager sur le forum.
    Je partage avec toi tous les arguments que tu énumères.

    Stéphane

    Consultant PluXml

    Ancien responsable du projet (2010 à 2018)

  • fdv a écrit:
    Bonsoir,

    Ayant vu ce site à plusieurs reprises dans mes referers (je suis l'auteur de l'article sur les usines à gaz sus mentionnées), et aimant, d'une manière générale, donner mon avis sur tout, surtout quand on en me le demande pas, j'ai 2-3 remarques à faire en passant.

    @Audiofeeline : je ne sais pas si PluXml dispose d'un système de cache statique (pas trouvé cette information, mais si c'est le cas, ce serait bien de le mettre en avant dans les features importantes), mais dans tout les cas, ton site risque de se retrouver avec de gros problèmes d'I/O
    – Si ton site a pas mal de commentaires, problèmes d'accès concurrentiels aux fichiers en écriture pour l'enregistrement des commentaires.
    – Si pas de cache, risque d'atteindre rapidement le maximum de descripteurs de fichiers ouverts en même temps, d'autant qu'il n'est jamais très élevé chez les hébergeurs mutualisés.

    @Alex7995 : Je pense perso que c'est une erreur. Autant faire son blog est top pour apprendre, autant en créer un à des buts de mise en production recouvre des enjeux – notamment de sécurité et de performances – qu'il ne faut pas prendre à la légère (XSS, SQL injections, CSRF...). Quand tu vois le nombre de vulnérabilités déclarées (ou non) dans des outils comme Wordpress ou Joomla alors qu'ils sont développés par des professionnels plutôt compétents (je ne dis pas que tu ne l'es pas), et audités avant release par un paquet de monde, je pense que le mieux est encore d'utiliser les outils à ta disposition, quitte à les tuner un peu selon tes besoins (et puis, pourquoi vouloir réinventer la roue ?).

    Mes 2 cents.
    J'ai un assez bon niveau en PHP. Je peux parfaitement réaliser ceci de manière sécurisé.
    Pourquoi pas utiliser les outil à disposition ? Parce qu'il me plaisent pas ... J'ai pas besoin d'une interface d'administration, j'ai pas besoin de pleins de choses que contient WordPress ! Mais je vais quand même l'utiliser, il évolueras surement plus vite que mon propre script ;)
    Et pour PluXml, l'accès concurrentiel, les commentaires sont enregistrés chacun dans un fichier séparé (sa fait pas mal de fichiers à mon avis quand on commence à avoir pas mal de commentaires ...
  • @fdv et @Alex7995 : Effectivement PluXml crée 1 fichier XML par commentaire et 1 par article mais n'utilise pas de système de cache.
    Cependant, il faut savoir que le moteur ouvre que très peu de fichiers XML, il se sert en premier lieu d'expressions régulières sur le nom du fichier afin d'obtenir un grand nombre d'informations (et faire un élagage conséquent sur les fichiers à ouvrir) :
    - pour un commentaire => le nombre de commentaires d'un article, l'id, la date de parution, le statut, l'article attaché, etc.
    - pour un article => le nombre d'articles d'une catégorie, l'id, la date de parution, l'url, la catégorie attachée, etc
    On a donc au final que très peu de descripteurs de fichiers ouverts et les performances de votre blog PluXml sera très dépendant de votre système de fichiers
  • J'étais en train de relire le topic et j'ai eu une idée.
    Pour ceux qui ont la possibilité, ils peuvent monter les fichiers XML dans un ramdisk, et faire un système qui va répliquer sur le disque dur, de cette façon, les I/O en lecture seront extrêmement mieux gérables qu'avec un disque normal. Et partant de là je pense qu'on peux monter en performance de manière assez importante.
  • Sinon je propose ici un moyen simple pour installer une cache :
    http://amoweb.fr/?article68/booster-encore-plus-pluxml
    Mais elle n'est utile qu'a partir de quelques centaines d'articles et de commentaires.
  • @Alex,

    A noter que Pluxml pour rappel s'utilise de 2 façons voir les 2 (Blog / Cms).

    Pas facile de cibler plusieurs utilisateurs sachant que la politique de PluXml et de ce vouloir léger.

    Sinon attends encore un peu la nouvelle version qui se veux prometteuse niveau performances et rapidités.
  • Frédéric a écrit:
    @Alex,

    A noter que Pluxml pour rappel s'utilise de 2 façons voir les 2 (Blog / Cms).

    Pas facile de cibler plusieurs utilisateurs sachant que la politique de PluXml et de ce vouloir léger.

    Sinon attends encore un peu la nouvelle version qui se veux prometteuse niveau performances et rapidités.
    Ok, elle a une date de sortie ?
  • FrédéricFrédéric Member
    juillet 2010 modifié
    Aucune date de sortie pour le moment désolé.
Connectez-vous ou Inscrivez-vous pour répondre.