mon discours est sans doute un peu confus, voila un schema qui illustre mieux ce que je veux dire

donc au vu de ce schema ce qu'il te faut est une bdd de type AP (qui à le meme inconvénient qu'une mise en cache à savoir aucune garantie qu'on accède bien aux donnée les plus récentes)

Tu dois faire un méga site que tu as besoin de miroirs?

Personnellement, non.

Mais c'est une question que je me pose à propos d'une idée que j'ai eu il y a quelque temps déjà, dans ce post.

Une sorte de P2P pour site web. J'avais pas trop continué l'idée, par manque de compétences mais surtout d'idée.
Depuis que l'ODDNS à émergé, je recommence à me poser des questions.
Un des principaux problème pour un P2P de site web, c'est les bases de données. Comment faire pour synchroniser le tout en un minimum d'action. Le système de cache devient important à ce moment, car il permet une rapide propagation des données sans intervenir sur la base de données (et donc améliorant les perf). Mais peut-être que je me trompes de question, je ne sais pas, je cherche

Mathieu147 a écrit :

C'est uniquement pour une question de performances que tu veux mettre en place ce genre de chose?

Hé bien je m'interroge sur la gestion des performance.

La question des performances vs de la facilité de la programmation, ou de privilégier le CPU vs privilégier la bande passante ou les accès disque vs les accès à la BDD ne sont pas faciles à résoudre et sont surtout une question de choix.

Si tu regardes par exemple les langages de programmation, tu pourrais faire tout ce que tu veux en assembleur, mais ce serait très difficile à maintenir et très compliqué à écrire. Tu pourrais utiliser le C et avoir presque des aussi bonnes performances mais c'est beaucoup plus facile à maintenir. Puis il y a les langages de plus haut niveau qui ont des performances pas aussi élevées mais qui sont plus confortables à utiliser.

Si les langages de plus haut niveau sont plus confortables à utiliser, c'est que les langages de plus bas niveau sont plus complexes. Et donc, tu mets sans doute plus de temps pour écrire ton programme, et ils ont des meilleurs performances à condition que le programme soit correctement écrit.

Ici, c'est la même chose: si tu mets en place un système de cache, tu pourras donc avoir de meilleures performances, mais uniquement si tu écris correctement ton système. De plus, le temps que tu vas passer à écrire ton système de cache ne sera pas passé à autre chose et tu vas peut-être prendre du retard dans ton développement.

Inévitablement, ton système de cache va apporter des bugs et des conditions à vérifier pour le reste de ton application.

Je rejoins mon propre avis d'hier matin (:D) où je disais que, comme pour tout, il faut peser le pour et le contre. J'ai tendance à dire que si tu veux faire un système d'affichage d'articles qui sont récupérés en une seule requête, tu vas mettre en place un système très compliqué pour gagner 0,2% de performance. Clairement, ça ne vaut pas le coup.

Ceci dit, je ne connais pas ton application et je ne saurais pas te dire si tu dois ou non mettre un cache. Moi personnellement j'en mets pour les éléments assez évidents. Par exemple, j'ai un système de redimensionnement d'images dans mon CMS, et les images redimensionnées sont cachées parce que j'ai remarqué que la différence de performance était très clairement visible (affichage quasiment instantané vs plusieurs secondes de chargement).

Tu dois faire un méga site que tu as besoin de miroirs?

parce qu'a relire, on est parti dans tous les sens. Et c'est pas évident de trouver le titre juste.
[Débat][Web] Quand et comment utiliser la mise en cache
(enfin bon, c'est pas sur que ce soit bcp mieux, et je voudrais pas te hijacker de ton topic non plus...)

C'est uniquement pour une question de performances que tu veux mettre en place ce genre de chose?

Hé bien je m'interroge sur la gestion des performance.
Mais également sur le fait que cela pourrait peut-être servir pour une gestion de site mirroir, faire en sorte que les mirroir se mettent à jours, sans devoir intervenir dans la base de données.

En même temps je ne sais pas vraiment ce que ça veut réellement dire, vu que je n'ai certainement pas les compétences pour juger mon propre code et avoir assez de recul pour dire si il est optimisé ou pas.

pour ton premier embêtement de réup tout le blog a chaque fois, je comprend, et je ne pense pas que les SWG soit adaptés à un hébergement mutualisé de base (= accès ftp+ serveur web), par contre dans le cas d'un serveur dédié (ou du moins suffisemment souple) le problème ne se pose pas, tu up uniquement tes modifications et le serveur refait le build (et si on considère que le blog est plus souvent visité que mis à jour, ça vaut carrément le coup)

concernant le dilemme bande passante vs CPU, j'aurais tendance à utiliser le CPU et économiser la BP (le premier dépend de toi alors que le second dépend du visiteur : le CPU du serveur ne change pas alors que la bp suivant la connexion du visiteur peux varier énormément)

Par contre, un truc qui me chagrine, pour le systeme de blog, on est d'accord que le dernier article et présenté en premier ? Donc si par exemple on a 10 pages d'articles, si on ajoute un article, le SWG va devoir réécrire ces 10 pages et les réuploader sur le site ...? C'est là que ca m'embête, devoir réup X pages pour chaque article ajouté ....
J'avais pensé faire un truc en JS, juste présenter sur les pages de blog un tout petit résumé de l'article et un lien qui ouvre l'article (géré par JS et xmlHttpRequest). Comme ça, les pages de blogs contiendront plus d'articles, et donc, moins de pages à upload ....!

Il y a aussi le XSLT, je trouve ça vraiment génial, mais dans mon appli, qui est prévu pour modifier des templates existantes, c'est un peu galère d'en faire un xsl (mais bien utile pour la gestion du menu par exemple, ou un systeme de news affiché sur toutes les pages, bien que cela peut aussi être fait via JS, mais avec bcp de requêtes serveurs nécessaire pour afficher une page) ....

J'ai une petite question, vu que les intervenant de ce thread ont l'air de connaitre le monde des serveurs, il est préférable de servir un gros fichier, ou plusieurs petits fichiers a la demande ?
D'un coté on utilse de la bande passante, de l'autre plus d'utilisation du serveur ... Parce que pour moi, l'idéal est de faire travailler le navigateur, donc via JS et un gros fichier qui contiendrait tous les articles (mais bon, si on a 200 articles, la taille du fichier risque d'être un peu trop importante, bien que si on compare le poids d'une image ... !)

Et quelle technologie la mieux adaptée, xslt, html/JS ou html/cgi (bien que le cgi ne soit pas installé sur tous les serveurs)

Bref, voilà mes questionnement.

perso ça fait un moment que je cherche un truc optimal pour faire ce genre de chose, et par manque de mot clé correct j'ai végété un moment jusqu'a trouver une solution simple et élégante (de mon point de vu):  les SWG (Static Website Generator) représenté entre autre par ikiwiki et blogofile (je te laisse googler un peu...)

Les caches peuvent être utiles de manière générale pour les données sur lesquelles tu as fait des traitements lourds que tu ne veux pas refaire à chaque fois. Si tes articles sont sous forme de HTML dans une BDD et que tu fais juste SELECT texte FROM articles WHERE id=5 puis que tu fais echo $article; ça ne vaut clairement pas la peine de mettre un système de cache.

Si tu as différents auteurs qui écrivent des articles, et que tu fais une page de présentation par auteur avec les résumés des articles qu'ils ont écrits, le nombre d'articles, et plein d'infos qui sont dispatchées dans plein de tables et de fichiers, et bien là, ça ne vaut pas la peine non plus Parce que ta page d'auteur ne sera sans doute pas très souvent visitée donc tu vas complexifier ton application avec une gestion du cache sans gagner grand chose en performance.

L'histoire du menu des catégories d'un site e-commerce que j'ai donné ci dessus par contre justifie un cache.

Conditions pour qu'un cache vaille la peine d'être mis en place: traitement lourd, page affichée souvent, beaucoup de données à rechercher dans la base avec des requêtes complexes.

Je parle bien sûr de cache pour la BDD uniquement, parce que c'est de ça que tu parles, mais si tu fais par exemple des traitements d'image avec GD, il faut cacher le résultat parce que ces traitements sont lourds en termes de CPU.

- Cache qui se met à jours toutes les X minutes.
- Cache qui est à jours tout le temps (chaque modification met à jours le cache).
- Ou les deux, en fonction du type de données ou d'affichage.

Rien que ça, j'ai du mal à savoir les avantages et les inconvénients des méthodes.

On m'a souvent dit que charger une page déjà construite était plus rapide que de charger un script PHP qui génère une page.
Mais la recherche de données est plus rapide dans une base de données relationnelle (tu m'étonnes, sinon ça s’appellerait pas "relationnelle").
Donc si je veux pouvoir faire en sorte que mes articles soient compris dans une recherche, il faut qu'ils soient dans la base de données, mais si j'ai envie de sauvegarder des ressources, il faut que je les mettent dans le cache, etc..,etc...

Ptin, plus jamais j'irais au boulot en rentrant de soirée xD J'ai mal au crâne xD

EDIT : En tout cas, merci à vous deux, vos explication m'éclaire quand même pas mal