Quel script de forum choisir ?
- Auteur de la discussion WebRankInfo
- Date de début
WRInaute occasionnel
WebRankInfo a dit:
Je serais curieu de voir un peu le résultat..
Il est clair que le plus utilisé serait phpbb
mais ce qui m'interesserait ca serait de voir ce que les webmasters utilisent
Je pense que les webmasters restent sur leur premier choix
difficile de mettre à l'eau des heures passées à comprendre un systeme pour changer du jour au lendemain
c'est un topic dialogue de sourds
Bonsoir, juste pour répondre à quelques remarques dans le sujet.
Tout d'abord concernant la remarque disant que les accès fichiers sur internet sont plus rapide que les requètes SQL, c'est faux pour deux raisons :
1) Les bases de données relationelles sont stoquées sous formes de fichier (sauf cas exeptionel généralement en cas de scripts éphémères ou c'est stoqué en heap), donc requète SQL = accès fichier
2) Tout dépend du serveur utilisé, la majorité du temps les serveurs de fichiers et serveurs SQL sont séparés, si le serveur de fichier est nul les accès fichiers prendront plus de temps que les requètes. Les serveurs SQL sont généralement installés sur des machines très performantes.
Ensuite pour la mise en cache intégrale d'un forum (chaque sujet visité par un visiteur est stoqué en HTML), c'est impossible de mettre en oeuvre cette solution de façon pour la simple raison que si c'étais faisable tout serait fait en HTML. Le principe du PHP c'est le dynamisme, et vouloir rendre statiques toutes ces pages c'est aller à l'encontre de gros problèmes. Comme déjà dit plus haut par d'autres intervenants, si un membre gagne +1 a son compteur de message il faut remettre en cache tous les sujets dans lesquels il a posté (pour peu qu'il ait posté dans 200 sujets différents ca fait déjà du gros boulot pour le serveur). La seule façon de mettre en cache des sujets serait de n'afficher que le script minimum des informations : le titre, le contenu du message, le nom de l'auteur, la date.
Là c'est clair que ton forum va apprécier tout de usite, tu réduits la charge par 100 au moins ... mais bon fini la convivialité, à ce prix là autant se programmer un forum en deux pages PHP avec deux tables sql max. Tout ça pour dire que cette solution miracle est très difficilement envisageable pour une grosse communauté.
Personellement je suis plutôt partisant du libre, aussi dans les forums cité Vbulletin et IPB je les classe en bas du classement. Surtout que les forums payants offrent largement moins de support que les forums libres (logique). Je comprend qu'un webmaster souhaite investir en argent pour son forum, ca peut dans pas mal de cas être vite rentabilisé, mais c'est la solution de facilité d'utiliser ces forums alors que des alternatives gratuites ne demandent qu'à être davantages reconnues. (PS : IPB + accessibilité = :/, payer pour un forum non accessible c'est pas top).
Aujourd'hui, les forums doivent intégrer au max les nouvelles technologies. L'époque PHP3 et découverte du PHP est révolue, la création du code source doit aller dans ce sens. Un programme open source doit avoir un code source lisible. Un code source lisible c'est :
1) Un code qui suit une norme
2) Un code qui est structuré
3) Un code qui est commenté
4) Un code qui est correctement indenté
Ca parait logique, mais très peu de forums remplissent ces conditions. phpBB est même le seul forum actuellement que je trouve lisible, le code source est clair et aéré, on apprend bien plus à lire phpBB qu'a essayer de déchiffrer les multiples CSS de punBB. Souvent un bon paquet de forum sont écrit de façon faiblement indentée (ce que je trouve impensable pour un projet open source, ne pas indenté son code le rend illisible pour les autres et pour sois même), et pas mal de forums ne sont pas structurés.
Quand je parlais des nouvelles technologies en PHP, je voulais parler par exemple de la programmation objet. Certe la poo date pas d'hier. Mais trop peu de développeur PHP l'utilisent alors que c'est clairement un outil indispensable pour un gros projet. Dans plusieurs forums connus que j'ai décortiqué la poo est quasiment inexistante, quand il y en a c'est utilisé par ci par là au gré du vent. c'est pourtant dommage, développer des classes pour son forum permet en plus d'en faire profiter les autres, ca permet de profiter de l'héritage, etc etc je vais pas ennoncer tous les concepts de la poo.
Pour prendre un exemple de forums, j'ai télécharger SMF pour tester l'autre jour, j'ai été direct charmé par les fonctions qu'il propose, il n'y a pas a dire ils ont fait du super boulot pour l'administration (notament l'installeur de mod, et les accès en streaming sur le site). Ensuite j'ai voulu regarder le code source, et là surprise TOUS les fichiers PHP tiennent dans un dossier Sources/, la plupart sont des énormes fichiers de + de 50ko, aucune POO tout est en fonction ce qui est illogique et force l'utilisation de globales dans tous les sens, bref code source clairement illisible ... Dommage mais je comprend pas qu'on soit capable de coder des fonctiosn vachement sympa sans etre capable de coder de façon organisé. un forum réuni dans un dossier Sources/ avec des fichiers de 50ko c'est clairement un calvers à déchiffrer.
Donc en plus d'avoir un code source lisible, les forums doivent implémenter un système de cache, ce qui parait indispensable. Les mises en cache de données sont de plus en plus répandues, et il n'est vraiment ps dur d'en développer un qui puisse mettre en cache les données importantes des forums. Par exemples les thèmes. phpBB2, ne contient aucun système de cache. Un système de cache de template est prévu mais non intégré au code, donc très peu de webmaster l'ont installé (il faut fouiller le répertoire contrib/ pour trouver). Pas mal de forums ne mettent pas en cache leurs données, ce qui est dommage car c'est généralement un bon gain de temps dans l'execution des scripts PHP, et ca peut souvent alléger le serveur en lui évitant les même calculs à répétition.
Pour FSB2, je l'ai programmé en suivant mes idéaux, donc j'ai fait en sorte que le code source soit très clair, commenté, lisible et j'ai penser le forum entier en programmation objet. Pour les débutants ca parait plus dur à lire (le procédural c'est le paradi des débutants, niveau facilité de lecture), mais une fois passé le cap de comprendre ce qu'est un objet on comprend de suite les interactions du forum avec les différentes classes. J'ai aussi intégré un système de cache qui met en cache pas mal de requètes SQL, la compilation des thèmes, les fichiers XML parsés, les résultats des recherches, etc..
Bon tout ça pour réagir sur quelques points techniques que devraient intégrer les forums, bien sur il y a beaucoup plus a dire, en bien comme en mal, mais ca serait se lancer dans un trop long discours
Bonne soirée.
Tout d'abord concernant la remarque disant que les accès fichiers sur internet sont plus rapide que les requètes SQL, c'est faux pour deux raisons :
1) Les bases de données relationelles sont stoquées sous formes de fichier (sauf cas exeptionel généralement en cas de scripts éphémères ou c'est stoqué en heap), donc requète SQL = accès fichier
2) Tout dépend du serveur utilisé, la majorité du temps les serveurs de fichiers et serveurs SQL sont séparés, si le serveur de fichier est nul les accès fichiers prendront plus de temps que les requètes. Les serveurs SQL sont généralement installés sur des machines très performantes.
Ensuite pour la mise en cache intégrale d'un forum (chaque sujet visité par un visiteur est stoqué en HTML), c'est impossible de mettre en oeuvre cette solution de façon pour la simple raison que si c'étais faisable tout serait fait en HTML. Le principe du PHP c'est le dynamisme, et vouloir rendre statiques toutes ces pages c'est aller à l'encontre de gros problèmes. Comme déjà dit plus haut par d'autres intervenants, si un membre gagne +1 a son compteur de message il faut remettre en cache tous les sujets dans lesquels il a posté (pour peu qu'il ait posté dans 200 sujets différents ca fait déjà du gros boulot pour le serveur). La seule façon de mettre en cache des sujets serait de n'afficher que le script minimum des informations : le titre, le contenu du message, le nom de l'auteur, la date.
Là c'est clair que ton forum va apprécier tout de usite, tu réduits la charge par 100 au moins ... mais bon fini la convivialité, à ce prix là autant se programmer un forum en deux pages PHP avec deux tables sql max. Tout ça pour dire que cette solution miracle est très difficilement envisageable pour une grosse communauté.
Personellement je suis plutôt partisant du libre, aussi dans les forums cité Vbulletin et IPB je les classe en bas du classement. Surtout que les forums payants offrent largement moins de support que les forums libres (logique). Je comprend qu'un webmaster souhaite investir en argent pour son forum, ca peut dans pas mal de cas être vite rentabilisé, mais c'est la solution de facilité d'utiliser ces forums alors que des alternatives gratuites ne demandent qu'à être davantages reconnues. (PS : IPB + accessibilité = :/, payer pour un forum non accessible c'est pas top).
Aujourd'hui, les forums doivent intégrer au max les nouvelles technologies. L'époque PHP3 et découverte du PHP est révolue, la création du code source doit aller dans ce sens. Un programme open source doit avoir un code source lisible. Un code source lisible c'est :
1) Un code qui suit une norme
2) Un code qui est structuré
3) Un code qui est commenté
4) Un code qui est correctement indenté
Ca parait logique, mais très peu de forums remplissent ces conditions. phpBB est même le seul forum actuellement que je trouve lisible, le code source est clair et aéré, on apprend bien plus à lire phpBB qu'a essayer de déchiffrer les multiples CSS de punBB. Souvent un bon paquet de forum sont écrit de façon faiblement indentée (ce que je trouve impensable pour un projet open source, ne pas indenté son code le rend illisible pour les autres et pour sois même), et pas mal de forums ne sont pas structurés.
Quand je parlais des nouvelles technologies en PHP, je voulais parler par exemple de la programmation objet. Certe la poo date pas d'hier. Mais trop peu de développeur PHP l'utilisent alors que c'est clairement un outil indispensable pour un gros projet. Dans plusieurs forums connus que j'ai décortiqué la poo est quasiment inexistante, quand il y en a c'est utilisé par ci par là au gré du vent. c'est pourtant dommage, développer des classes pour son forum permet en plus d'en faire profiter les autres, ca permet de profiter de l'héritage, etc etc je vais pas ennoncer tous les concepts de la poo.
Pour prendre un exemple de forums, j'ai télécharger SMF pour tester l'autre jour, j'ai été direct charmé par les fonctions qu'il propose, il n'y a pas a dire ils ont fait du super boulot pour l'administration (notament l'installeur de mod, et les accès en streaming sur le site). Ensuite j'ai voulu regarder le code source, et là surprise TOUS les fichiers PHP tiennent dans un dossier Sources/, la plupart sont des énormes fichiers de + de 50ko, aucune POO tout est en fonction ce qui est illogique et force l'utilisation de globales dans tous les sens, bref code source clairement illisible ... Dommage mais je comprend pas qu'on soit capable de coder des fonctiosn vachement sympa sans etre capable de coder de façon organisé. un forum réuni dans un dossier Sources/ avec des fichiers de 50ko c'est clairement un calvers à déchiffrer.
Donc en plus d'avoir un code source lisible, les forums doivent implémenter un système de cache, ce qui parait indispensable. Les mises en cache de données sont de plus en plus répandues, et il n'est vraiment ps dur d'en développer un qui puisse mettre en cache les données importantes des forums. Par exemples les thèmes. phpBB2, ne contient aucun système de cache. Un système de cache de template est prévu mais non intégré au code, donc très peu de webmaster l'ont installé (il faut fouiller le répertoire contrib/ pour trouver). Pas mal de forums ne mettent pas en cache leurs données, ce qui est dommage car c'est généralement un bon gain de temps dans l'execution des scripts PHP, et ca peut souvent alléger le serveur en lui évitant les même calculs à répétition.
Pour FSB2, je l'ai programmé en suivant mes idéaux, donc j'ai fait en sorte que le code source soit très clair, commenté, lisible et j'ai penser le forum entier en programmation objet. Pour les débutants ca parait plus dur à lire (le procédural c'est le paradi des débutants, niveau facilité de lecture), mais une fois passé le cap de comprendre ce qu'est un objet on comprend de suite les interactions du forum avec les différentes classes. J'ai aussi intégré un système de cache qui met en cache pas mal de requètes SQL, la compilation des thèmes, les fichiers XML parsés, les résultats des recherches, etc..
Bon tout ça pour réagir sur quelques points techniques que devraient intégrer les forums, bien sur il y a beaucoup plus a dire, en bien comme en mal, mais ca serait se lancer dans un trop long discours
Bonne soirée.
Heu, c'est quoi le lien de cause à effet payant/moins de support ?Genova a dit:
MySQL le fait par défaut (http://dev.mysql.com/doc/refman/5.0/en/query-cache.html)Genova a dit:
Genova a dit:
Entre faire une dizaine de requêtes et ouvrir 10 fichiers : as tu déjà fait le test ?
(sans compter que l'ouverture de fichier n'amène pas a des erreurs : "Trop de connexion" que l'on connait avec mysql..mais ça je l'ai déjà dis plus haut...)
Si, si c'est faisable...c'est un gros boulot, mais c'est faisable.Genova a dit:
Genova, tu sais bien que même si les données de la base de données sont stockées sous forme de fichiers, il faut bien solliciter le serveur MySQL, ça reste plus gourmand qu'un simple accès à un fichier (d'ailleurs c'est ce que tu sembles dire quand tu parles de la mise en cache d'un forum avec réduction par 100 de la charge).
Je ne comprends pas non plus pourquoi ça te semble logique qu'en payant on ait moins de support.
Cela dit merci pour ton message détaillé qui offre le point de vue d'un développeur Open Source.
Je ne comprends pas non plus pourquoi ça te semble logique qu'en payant on ait moins de support.
Cela dit merci pour ton message détaillé qui offre le point de vue d'un développeur Open Source.
Et bien fait le test, va sur IPB.com (je parle de IPB.com, pas de IPB.fr qui est un site indépendant à IPB), et demande leur du support
Les forums payants sont moins côtés, et le support est généralement assuré par des personnes payées pour le faire. Un forum payant a une communauté moins développée qu'un forum libre, le support en patie donc forcément.
Oui mais tu es tout de même obligé d'accéder au serveur SQL. Le but de faire un cache SQL côté serveur de fichier c'est de limité les accès au serveur MySQL, qui est souvent bien pris.
Oui, l'ouverture de 10 fichiers prend plus de temps que 10 requètes SI le serveur de fichier est moins bon que le serveur SQL. Dans mon message c'est pourtant clairement expliqué. Et ca arrive parfois que le serveur de fichier soit plus lent, j'ai déjà du bosser sur ce type de configuration. De toute façon un serveur de base de donnée relationelle restera toujours plus performanant qu'un système par de fichier. Essaie de faire un forum en stoquant tout dans des fichiers (messages, membres, sujets), tu va vite voir la perte de performanance et les corruptions de fichiers ..
Oui dans mon message j'ai aussi dit que c'étais faisable, à condition de ne garder que les informations essentielles d'un forum : fini les compteurs de posts, les avatars, les signatures, les rangs, tout ce qui est dynamique quoi. Si tu conserves ces infos tu dois recréer toutes les pages en cache à chaque update d'avatar, signature, etc ...
Donc mettre en cache les pages des sujets en html pour accélérer le serveur mais pour perdre 95% de la convivialité, à ce prix autant ne pas installer de forum du tout.
PS : webrankinfo : Pour MySQL oui j'en parle dans ce message, mais comme dit plus haut tout dépend des performanances des deux serveurs, maintenant je suis d'accord qu'un serveur de fichier est souvent plus rapide, mais ce n'est pas vrai dans 100% des cas.
c'est pas si fréquent que ça de changer d'avatar ou de signature ! Ca vaut carrément le coup de mettre en cache.
Le pb du nb de posts affiché à côté du pseudo est plus embêtant, mais franchement c'est vraiment pas indispensable que le compteur soit absolument à jour.
Penses-tu à d'autres éléments dynamiques qui sont difficiles à mettre en cache ? Il doit y en avoir d'autres... c'est pour ça que je ne l'ai toujours pas fait sur WRI ;-)
Il faut faire gaffe aux droits des forums (par exemple ne pas mettre en cache les messages dans les forums privés ?), il faut mettre a jour le cache du sujet en cas de modération / édition / ajout de message, toutes les info personelles d'un membre sont dynamique (effectivement la présence du compteur de message est pas indispensable).
Il doit y avoir pas mal de petits trucs en plus. Dans tous les cas si tu arrives a gérer ça sans trop de problèmes, chapeau
Bonne chance.
Il doit y avoir pas mal de petits trucs en plus. Dans tous les cas si tu arrives a gérer ça sans trop de problèmes, chapeau
Bonne chance.
gné ???Genova a dit:Et bien explique comment tu comptes faire alors si tu dit que c'est faisable
tu veux pas que je te donne l'algo non plus?
plus sérieusement, crois moi c'est faisable.
(en y réfléchissant un peu tout le monde y conviendrait)
de toute manière c'est simple à prouver.
quand tu cherche tes données dans une bdd mysql, tu possède certaines fonctions qui te permettent la recherche, mais tout ça c'est grâce à php.
la c'est pareil, les fichiers, c'est la bdd sauf que les fonctions n'existe pas, il faut en gros créer le système qui permet de traiter les fichiers et donc de ressortir les données.
c'est kif kif, sauf que la bdd mysql par exemple sera plus lourde car un seul fichier par table, donc la recherche plus longue. en revanche lorsque l'on travail sur plusieurs petits fichiers, c'est bien plus rapide. l'inconvénient sur les multiples fichiers, est au niveau de la multitudes d'ouvertures, mais la lecture de données est largement plus rapide.
donc plus la base est consistante plus le système cache par fichier est intéressant. à savoir et c'est important, si tu est limité (on l'est toujours, dédié ou pas..) en nb de connexion, tu n'aura normalement presque pas d'erreur "Trop de connexion", et si ton système de traitement des fichiers est au point, tu n'aura pas de problèmes de corruptions de fichiers. :wink:
non, j'ai toujours parlé de système de cache par fichier...tu pourra vérifier en relisant peut être.. :roll:Genova a dit:
je ne sais même pas ce que tu entends par "cache de sortie HTML" : ça veut dire quelque chose ça ?
edit: en plus il me semble que tu parlais également de ça, sinon je ne vois pas trop de quoi tu parlais ?!
je n'ai jamais prétendu faire une base de donnée en php... 8OGenova a dit:
en revanche un système permettant la gestion des fichiers de manière sûre, ça oui.
et lorsque je comparais cela à une bdd, c'était à titre d'exemple.
maintenant dire que cela est abérant est un peu irationelle !
je te pensais plus ouvert au dialogue...c'est abérant !
Dans ce cas on s'est mal compris, enfin peu importe c'est pas important.
Donc si tu parles bien d'un cache HTML (je disais output html pour la simple raison que ca consiste à récupérer le buffer de sortie et à le mettre en cache dans un fichier), je voulais juste avoir plus d'info sur comment tu comptes t'y prendre.
Comment comptes tu gérer le fait que si une personne change d'avatar ça met à jour les pages HTML ? Comment comptes tu gérer le changement de signature ? L'édition d'un message ? La modération d'un message ? Bref toutes les infos qui font qu'une page est dynamique à la base. Tu dits que c'est faisable, je suis d'accord, mais que ce soit implémentable sur un forum comme phpBB je reste très dubitatif. Donc je voulais savoir comment comptes tu t'y prendre
Donc si tu parles bien d'un cache HTML (je disais output html pour la simple raison que ca consiste à récupérer le buffer de sortie et à le mettre en cache dans un fichier), je voulais juste avoir plus d'info sur comment tu comptes t'y prendre.
Comment comptes tu gérer le fait que si une personne change d'avatar ça met à jour les pages HTML ? Comment comptes tu gérer le changement de signature ? L'édition d'un message ? La modération d'un message ? Bref toutes les infos qui font qu'une page est dynamique à la base. Tu dits que c'est faisable, je suis d'accord, mais que ce soit implémentable sur un forum comme phpBB je reste très dubitatif. Donc je voulais savoir comment comptes tu t'y prendre
et bien je vois que l'on parlait de la même chose finalement, tu t'es emporté un peu vite sur ce coup :wink:
Cette méthode, tu en conviens, n'est pas adaptée dans le cadre d'un forum, du fait que le fichier cache n'est pas "exploitable" comme une bdd (d'où mon exemple avec une bdd). Dans le cas d'un forum c'est bien plus compliqué, je te l'accorde.
Cela répond donc en partie à ceci :
En terme de gain de temps, c'est encore à testé en cas réel, en revanche il y aura toujours les autres avantages (limitation de l'utilisation du serveur de bdd, moins de ressource utilisé, etc.). Mais je pense qu'avec un gros forum le gain en temps doit se faire ressentir et largement (du fait du % de lecture par rapport au % de modif).
Je ne procède pas comme ça, car ainsi justement tu bufferise le tout avant de l'enregistrer dans un seul et unique fichier, pour ensuite l'afficher. C'est une excellente solution, en effet, lorsqu'il s'agit d'une simple page web (une actualité, etc.)Genova a dit:
Cette méthode, tu en conviens, n'est pas adaptée dans le cadre d'un forum, du fait que le fichier cache n'est pas "exploitable" comme une bdd (d'où mon exemple avec une bdd). Dans le cas d'un forum c'est bien plus compliqué, je te l'accorde.
Cela répond donc en partie à ceci :
Alors pour ce qui est de l'implémenter sur un forum phpBB je n'en est rien dis, pour la simple et bonne raison que je n'en est pas et je ne le connais pas (dans sa source bien entendu).Genova a dit:Tu dits que c'est faisable, je suis d'accord, mais que ce soit implémentable sur un forum comme phpBB je reste très dubitatif. Donc je voulais savoir comment comptes tu t'y prendre
Modifier signature, avatar, etc..ce n'est pas le plus compliqué.Genova a dit:
En terme de gain de temps, c'est encore à testé en cas réel, en revanche il y aura toujours les autres avantages (limitation de l'utilisation du serveur de bdd, moins de ressource utilisé, etc.). Mais je pense qu'avec un gros forum le gain en temps doit se faire ressentir et largement (du fait du % de lecture par rapport au % de modif).
C'est dingue d'arrivé à être convaincu d'une règle générale comme ça en ne se basant que sur un exemple...Genova a dit:Et bien fait le test, va sur IPB.com (je parle de IPB.com, pas de IPB.fr qui est un site indépendant à IPB), et demande leur du support
Les forums payants sont moins côtés, et le support est généralement assuré par des personnes payées pour le faire. Un forum payant a une communauté moins développée qu'un forum libre, le support en patie donc forcément.
J'ai bossé sur un logiciel de forum payant pendant plusieurs années, et je ne pense pas que la moindre communauté de n'importe quel forum libre puisse arriver à la cheville de ce qu'on faisait au niveau du support
Heu, entre tapper sur le serveur SQL qui a ça en mémoire vive et regarder sur le disque dur de ton serveur web, aller regarder sur le serveur SQL est *lègerement* plus économiqueGenova a dit:
Après si tu parle d'un serveur web avec 5 DD SCSI 15ktours en raid sous exploité et d'un serveur SQL à l'autre bout de la planète hébergé sur un ordinateur portable, solicité à mort ; oui ton option semble la meilleur
Genova, ce n'est pas si insurmontable que ça de déclencher la mise à jour du cache si un message est édité, un avatar ou une signature modifié(e). Dans certains cas ça peut déclencher le recalcul de pas mal de fichiers en cache mais comparé aux sollicitations de phpBB sans cache, je pense que c'est rentable.
Notre ami fandeciné a développé un tel système de cache pour phpBB. Moi je m'arrête là dans les discussions car y'en a qui s'y connaissent mieux que moi ;-)
Notre ami fandeciné a développé un tel système de cache pour phpBB. Moi je m'arrête là dans les discussions car y'en a qui s'y connaissent mieux que moi ;-)
Webrankinfo : dans tous les cas tu as raison, ça mérite reflexion. Je vais essayer de réfléchir sérieusement à l'implémentation d'un tel cache pour FSB2, je verrai si c'est gérable ou pas.
? Enfin je me base surtout sur les retours utilisateurs des gens décus par IPB ou vbulletin, c'est surtout IPB qui a une sale réputation côté support, maintenant c'est vrai que je me suis pas interessé au support des autres forums, le mot "forum propriétaire et payant" a tendance à me rebuter, donc tu as peut etre raison pour certains forums payants.
PS : A noter que le cache que je développe n'est pas forcément mis en cache par fichier, si ton serveur a un cache PHP installé (turck mmcache, eaccelerator, apc, etc ..) fsb2 se base en priorité sur ces api pour les mises en cache, ce qui peut etre nettement plus rapide que les mises en cache par fichier en php effectivement.
Communauté phpBB comprise
? Enfin je me base surtout sur les retours utilisateurs des gens décus par IPB ou vbulletin, c'est surtout IPB qui a une sale réputation côté support, maintenant c'est vrai que je me suis pas interessé au support des autres forums, le mot "forum propriétaire et payant" a tendance à me rebuter, donc tu as peut etre raison pour certains forums payants.Tout le monde n'est pas de cet avi, j'ai déjà suivi pas mal de discussions a ce sujet sur divers forums (area51.phpbb.com il me semble), et un cache SQL peut souvent etre bénéfique dans pas mal de cas. Je ne suis pas assez calé en serveur après pour savoir si c'est ok ou pas, la seule chose que je sais c'est que certains hébergeurs limitent le nombre de requètes SQL quotidienne, et que FSB2 a pour but d'etre portable, et donc un cache SQL peut aider dans ce genre de cas.
PS : A noter que le cache que je développe n'est pas forcément mis en cache par fichier, si ton serveur a un cache PHP installé (turck mmcache, eaccelerator, apc, etc ..) fsb2 se base en priorité sur ces api pour les mises en cache, ce qui peut etre nettement plus rapide que les mises en cache par fichier en php effectivement.
La communauté phpbb n'a accès aux serveurs de ses "clients", vois pas en direct les erreurs qui peuvent se produire sur le serveur, ne gère pas les upgrades lors de mise a jour du logiciel, ...Genova a dit:Communauté phpBB comprise
C'est pas la même chose là, si tu fais un cache de ce genre pour optimiser les perf ou pour parer à moindre cout les limitations de certains hébergeurs !Genova a dit:
Dans un contexte "normal" sans ce genre de limitations, le résultat est directement accessible en mémoire vive avec mysql, qui gère lui même la durée de validité du cache et tout, ça sert a rien de se compliquer la vie pour faire la même chose en moins performant
Pourtant les benchmarks que j'ai fait en utilisation reel sur un serveur free disent le contraire Enfin on va pas chipoter sans fin ^^
Enfin on va pas chipoter sans fin ^^Effectivement c'est sur qu'effectuer du support sur un forum "limité" c'est nettement plus simple et efficace. Par limité je veut dire un forum géré par une société dérière (genre forumactif). Je parlais surtout des forums à installer soit même, le support est nettement différent, d'où ma remarque.
Heu, si, on va chipoter encore un petit peu : l'exemple de free rejoins à peu près ce que je donnais comme exemple avec le serveur web avec ses disque SCSI et le serveur SQL à 50000km hébergé sur un ordinateur portable... Il est de notoriété publique (et ce depuis des années) que les hébergement free sont pitoyables au niveau de la base de donnée... (testé et désaprouvé !Genova a dit:Pourtant les benchmarks que j'ai fait en utilisation reel sur un serveur free disent le contraire
)Fait tes benchmark dans des conditions a peu près réaliste avant de généraliser et d'aller donner des leçons :/
Tu te fourvoye là, forumactif vend pas de software, il vend uniquement de l'hébergement de forum. Moi je te parle de software installé sur ton propre serveur, pas forcément hébergé par le fournisseur de forumGenova a dit:
A titre indicatif tu bossais sur quel forum que j'aille voir ce qu'ils proposent ?
Oui, et vu que pas mal de personnes ont un forum chez free un cache est utile. Je n'ai pas fait que des benchmark chez free, ça va de sois, mais globalement les performances d'un cache SQL sont plutot bonnes. PhpBB3 intègre aussi un cache SQL, je doute qu'ils aient aussi choisi cette solution s'ils n'étaient pas sur de ce qu'ils faisaient et s'ils n'avaient pas eu un max de retours utilisateurs.
http://www.mesdiscussions.netGenova a dit:
Ils le mettent sur toutes leurs requetes ???
(note : phpbb, niveau perf, faut bien chercher pour trouver pire, donc les perdre en exemple sur un discussion axée performance, c'est pas l'idéal)
J'irais regarder ça ce soir tient, ça doit bien être téléchargeable quelque part leur version 3
Code:
phpbb, niveau perf, faut bien chercher pour trouver pireBien sur que non ils ne le mettent pas sur toutes leurs requètes. Il faut le faire sur les requètes qui sont plutot statiques (afin d'éviter a refaire le cache trop souvent). Par exemple la configuration du forum, les modérateurs des forums, etc ...
C'est pas cohérent ta phrase, tu admet que phpbb2 n'est pas performant puis tu dit qu'il est tip top en prennant pour exemple WRI...Genova a dit:
Et ton exemple est foireux, on ne peut pas dire qu'un script est performant en ne se basant que sur la rapidité qu'on observe au final. On a pas d'indiquations sur l'infrastruture le gérant, ni de la rapidité des autres types de forums sur cette même infrastructure... qui sait, peut être que derrière le forum WRI se cache un cluster de 15 serveurs, dans ce cas le moindre script pas performant pour un sous pourrait appariatre comme rapide... bon, ça n'est certainement pas le cas, mais c'est histoire d'illustrer
J'ai regardé un peu : en gros il y a une dizaine de requetes "type" qui sont potentiellement stockées sur le disque comparé à plusieurs milliers qui tournent... autant dire que le cache n'est pas des masses significatif devant le reste sur la génération d'une page à l'intérieur d'un sujetHawkEye a dit:
Et dans le cas de mysql en tout cas, qui intègre déjà un cache qui est mieux géré (expiration dès que le résultat devient obselète, comparé au timing mis au pifomètre pour phpbb), ce genre de système ne sert pas sauf si l'hébergement est à la sauce free.fre ou impose des limites au niveau du nombre de requète
Bah ecoute rien t'empèche d'aller les voirs et de leur expliquer. Tu sais ils bossent sur phpBB3 depuis plusieurs années, et je pense que des suggestions utilisateurs qui connaissent parfaitement le dommaine des serveurs, ils ont du en avoir un paquet. S'ils ont fait ce choix, vu le poid de phpBB sur la cmmunauté web (qui est le forum le plus utilisé, et largement), ils ont surement eu raison de le faire.
1) phpBB3 est largement plus performant que phpBB2
2) Que phpBB2, même s'il ne s'agit pas d'un forum TRES performant, est tout de même un forum qui a su faire ses preuves. Et de toute façon, la majorité du temps, si phpBB est considéré comme lourd c'est à cause des multiples MODS que les webmasters installent, mais sa version de base est tout a fait convenable.
PS : Les sources de Mesdiscussions sont publiques ou non diffusées ?
Je disais tout simplement que :
1) phpBB3 est largement plus performant que phpBB2
2) Que phpBB2, même s'il ne s'agit pas d'un forum TRES performant, est tout de même un forum qui a su faire ses preuves. Et de toute façon, la majorité du temps, si phpBB est considéré comme lourd c'est à cause des multiples MODS que les webmasters installent, mais sa version de base est tout a fait convenable.
PS : Les sources de Mesdiscussions sont publiques ou non diffusées ?
Pense par toi même au lieu de t'en remettre un "saint phpbb" : en quoi un cache avec des fichiers php peut être plus performant que le système de cache de mysql, dans le contexte utilisé ?Genova a dit:
nan nan nan, phpbb est très lourd de base, apparement c'est possible de l'optimiser un peu, mais ça reste une horreur pour gérer des forums de grande taille.
Et dans la version 3 il n'y a pas de grands chamboulements dans la structure (au niveau de la bdd surtout), ça risque pas de résoudre les problèmes liés aux gros forums
PS : non diffusées
Pourtant la structure change pas mal désolé de te contredire mais je connais phpBB2 très bien et j'ai eu le temps de regarder longuement le développement de phpBB3, ne serais ce que l'algo de modélisation des forums qui est je pense l'algo le plus optimisé (arbre par représentation intervallaire : http://sqlpro.developpez.com/cours/arborescence/). Il y a énormément de changement justement, j'ai du mal a comprendre comment tu peux dire ça sur un simple coup d'oeil.
Humour à part, comme je l'ai déjà dit plus haut, j'ai déjà suivi de nombreux débats sur la question du cache SQL sur les forums de développement de phpBB, et tout a été dit là bas. phpBB est le forum le plus utilisé actuellement, ce qui fait que le développement de phpBB3 a interessé toutes les personnes concernées par phpBB, que ce soit hébergeurs ou administrateurs. Et les arguments pour un cache SQL ont été donné, si c'étais une mauvaise solution je doute qu'ils l'aient implémenté. Je ne me prend pas pour un saint avec la vérité absolue, mais je pense qu'on peut leur faire confiance. Je vois mal comment tu peux remettre leur travail en doute. Si tu ne me crois pas va leur poser la question tu seras surpris du résultat. Je n'ai pas les connaissances pour argumenter leur choix, mais eux l'ont surement.
Mais je suis assez grand pour penser par moi même, merci tout de même de t'en inquiéter :mrgreen:
Humour à part, comme je l'ai déjà dit plus haut, j'ai déjà suivi de nombreux débats sur la question du cache SQL sur les forums de développement de phpBB, et tout a été dit là bas. phpBB est le forum le plus utilisé actuellement, ce qui fait que le développement de phpBB3 a interessé toutes les personnes concernées par phpBB, que ce soit hébergeurs ou administrateurs. Et les arguments pour un cache SQL ont été donné, si c'étais une mauvaise solution je doute qu'ils l'aient implémenté. Je ne me prend pas pour un saint avec la vérité absolue, mais je pense qu'on peut leur faire confiance. Je vois mal comment tu peux remettre leur travail en doute. Si tu ne me crois pas va leur poser la question tu seras surpris du résultat. Je n'ai pas les connaissances pour argumenter leur choix, mais eux l'ont surement.
Je me demande comment on peut affirmer ça avec un code source privé ... Comme tu l'as dit plus haut a juste titre les performances peuvent très bien être dues à un gros cluster. Mais bon faut bien faire vendre je supposer ^^mesdiscussions a dit:
Il y a toujours certaines abhérations au niveau des requetes : faire un order by date_du_post (champs de type datetime), c'est génial niveau performance, surtout quand on a une PK de type mediumint, autoincrémentée...Genova a dit:
Sur la table phpbb_posts, mettre un index sur post_time, c'est bien, mais si c'est uniquement sur ce champs, ça sert a quoi ?
Les requetes sont toujours de type : SELECT ... FROM ' . POSTS_TABLE . ' p, ' . TOPICS_TABLE . " t WHERE t.topic_id = $topic_id AND p.topic_id = t.topic_id ... ORDER BY p.post_time ASC
=> L'index il faudrait un index composé et non juste sur post_time, même pas besoin de faire un explain pour voir qu'il ne servira a rien cet index
C'est une mauvaise solution.
Bench à l'appui :
Temps avec le query cache de mysql : 1.378
Temps avec le cache sur le système de fichier : 20.791
(source : -http://www.mappemonde.net/bench.php)
Code:
<?php
include 'acm_file.php';
include 'cache.php';
include 'dbal.php';
include 'mysql4.php';
function elapsed($ini,$end,$round= 0) {
$start_u = substr($ini,0,10);
$start_s = substr($ini,11,10);
$stop_u = substr($end,0,10);
$stop_s = substr($end,11,10);
$start_total = doubleval($start_u) + $start_s;
$stop_total = doubleval($stop_u) + $stop_s;
return round($stop_total - $start_total,$round);
}
class user{};
$user= new user();
$phpbb_root_path = '';
$db = new dbal_mysql4();
$cache = new cache();
$cache->cache_dir = '';
$db->sql_connect('localhost', 'root', '', 'mappemonde');
$query = 'SELECT * FROM mappemonde.mpm_donnees_carte WHERE id_carte=1';
$nb_tests = 1000;
$t0 = microtime();
for ($i=0; $i<$nb_tests; $i++) {
$result = $db->sql_query($query);
$row = $db->sql_fetchrow($result);
//echo $row['id_carte'],'<br />';
$db->sql_freeresult($result);
}
$t1 = microtime();
for ($i=0; $i<$nb_tests; $i++) {
$result = $db->sql_query($query,3600);
$row = $db->sql_fetchrow($result);
//echo $row['id_carte'],'<br />';
$db->sql_freeresult($result);
}
$t2 = microtime();
echo '<br />Temps avec le query cache de mysql : ',elapsed($t0,$t1,3);
echo '<br />Temps avec le cache sur le système de fichier : ',elapsed($t1,$t2,3);
?>Je pense que ce bench est parlant : dans un cas j'utilise pas le système de cache de phpbb, dans un autre je l'utilise pour 3600 secondes.
Et forcément les perf tombent d'un coup.
Les seuls modifications apportées aux fichiers d'origine de phpbb (ceux inclus) c'est le define in_PHPBB qui est partit, et une mention "enegistrement de la requete" qui est affichée quand le système de cache enregistre le fichier de cache, pour être sur de ne pas faire la manip a chaque occurence (et donc être sur d'avoir un cache qui marche comme il devrait marcher).
Je le fais tourner en local et sur mon serveur dédié, même résultat, rapport de 15 entre les deux résultats.
Requete faite sur une table quasiment statique (pas d'update ou d'insert pendant la phase de test), avec un volume de données assez important (ce n'est pas juste un entier qui est rappatrié mais un mediumtext bien remplit accompagné d'entiers et tout...
Tu peux toujours aller contacter les clients de mesdiscussions, par exemple l'admin de hardware.fr, il est assez disponible sur son forum, tu lui demandera ce qu'il a comme système derrière son forum
M'intéresse pas de les contacter, je dit juste que prétendre que mesdiscussions surclasse en terme de rapidité ses concurents c'est très aléatoire sans script à l'appuie. Enfin c'est juste un détail.
Concernant ton benchmark on pouvait s'attendre à ça bien entendu. Ce qui ne change rien à l'utilité du cache SQL dans le cas d'un serveur SQL plus lent. Rien n'empèche a l'administrateur de son forum de désactiver le cache s'il estime que ce n'est ps bénéfique pour lui. C'est le role d'un administrateur de forum.
Donc tu conseillerais plutot de faire un order by sur la clef primaire ?
Concernant ton benchmark on pouvait s'attendre à ça bien entendu. Ce qui ne change rien à l'utilité du cache SQL dans le cas d'un serveur SQL plus lent. Rien n'empèche a l'administrateur de son forum de désactiver le cache s'il estime que ce n'est ps bénéfique pour lui. C'est le role d'un administrateur de forum.
Certe. Mais c'est vérifiable pour qui veut le faireGenova a dit:
Puis toute façon je m'en fiche un peu a vrai dire, de mon côté j'estime n'avoir pas grand chose a prouver hein
oui, puis surtout de le faire correctement
"Concernant ton benchmark on pouvait s'attendre à ça bien entendu"
Wha. Marrant. J'avais cru que le but de la manip c'était de gagner en performance, là on multiplie par 15 le temps d'exécution de la requête...
Ca devrait être désactivé par défaut, et ça ne devrait pas être une méthode à conseiller dans le cadre général pour optimiser le forum s'il rame, au contraire !
Mais je n'ai jamais mis en avant les temps d'execution. J'ai toujours mis en avant l'aspect pratique, vis à vis du serveur SQL, de la chose. Maintenant ça ne mène à rien, tu prétends que c'est inutile pour le serveur SQL, et dans d'autres sujets ils disent le contraire. J'ai davantage tendance à croire la majorité (et non, inutile de dire que c'est une majorité qui ne connait rien ). Enfin bon il n'y a rien à ajouter apparament tout a été dit.
). Enfin bon il n'y a rien à ajouter apparament tout a été dit.Ca pourrait etre interessant a avoir comme avi.
ajax a dit:
Le Savoir-vivre tu connais ?
Visiblement non...
Tonton Ohax va donc essayer d'apporter base qui je l'espère te permettra de consolider ton savoir vivre et donc tes relations avec tes petits camarades.
Si un sujet ne t'intéresse pas inutile de gâter le plaisir de ceux qui aiment.
En gros, quand on connais pas on ferme sa bouche, inutile de parler pour le plaisir de voir son nom s'afficher sur le forum.
Inutile d'étaler sa haine ;-).
Merci 8)
une question encore, que pense tu des requêtes utilisant les "fonctions" mysql du genre :
DATE_SUB(NOW(), INTERVAL 20 MONTH)
vaut-il mieux utiliser le php pour faire la conversion (en gros donner la date 20 mois avant par rapport à aujourd'hui) ou ce genre de requête n'est pas plus lourd en sql ?
DATE_SUB(NOW(), INTERVAL 20 MONTH)
vaut-il mieux utiliser le php pour faire la conversion (en gros donner la date 20 mois avant par rapport à aujourd'hui) ou ce genre de requête n'est pas plus lourd en sql ?
Que ce soit en mysql ou en php ça ne change pas grand chose côté performance (tant que tu fais pas un traitement sur le champs date de ta bdd dans le WHERE de ta requête !), là c'est plus a toi de voir si tu préfère faire le traitement côté serveur web ou côté serveur sqlthierry8 a dit:
ok merci.FlorentP a dit:
ben a vrai dire je n'ai pas le choix, j'ai bien une condition qui utilise un champ date dans la clause WHERE..comment faire autrement sachant que je n'ai pas d'autre indicatif de "classement".
enfin pour la fonction c'était surtout pour savoir si le traitement n'est fait qu'une seul fois ou autant de fois que d'enregistrements récupérés:
dans le même ordre d'idée en php:
à éviter:
for($i=0;$i<count($jesaispas);$i++)
à faire:
$x = count($jesaispas);
for($i=0;$i<$x;$i++)
"ben a vrai dire je n'ai pas le choix, j'ai bien une condition qui utilise un champ date dans la clause WHERE..comment faire autrement"
Nan, mais ça c'est bien !
C'est faire un truc genre :
WHERE date_du_message + INTERVAL 20 MONTH > NOW()
qui serait une horreur
Tant que le résultat est une valeur fixe, ça pose pas de soucis, ce que tu fais c'est bien :
WHERE date_du_message > NOW() - INTERVAL 20 MONTH
Si vraiment tu pense que ça peux avoir un impact, benchmark, mais le calcul de la date est insignifiant devant l'exécution de la requête, donc te prend pas la tête, fait ton calcul en SQL si tu trouve ça plus clean, ou en php si tu préfère avoir la donnée en php pour la suite par exemple
Nan, mais ça c'est bien !
C'est faire un truc genre :
WHERE date_du_message + INTERVAL 20 MONTH > NOW()
qui serait une horreur
Tant que le résultat est une valeur fixe, ça pose pas de soucis, ce que tu fais c'est bien :
WHERE date_du_message > NOW() - INTERVAL 20 MONTH
Si vraiment tu pense que ça peux avoir un impact, benchmark, mais le calcul de la date est insignifiant devant l'exécution de la requête, donc te prend pas la tête, fait ton calcul en SQL si tu trouve ça plus clean, ou en php si tu préfère avoir la donnée en php pour la suite par exemple
ma requête exemple : (ça c'est bon ?)
SELECT monchamp FROM matable WHERE date<DATE_SUB(NOW(), INTERVAL 20 MONTH)
je n'ai pas compris la différence entre ta première requête et la seconde : ( désolé :? )
pas bien : WHERE date_du_message + INTERVAL 20 MONTH > NOW()
bien : WHERE date_du_message > NOW() - INTERVAL 20 MONTH
edit start
ok je vois.. 8)
simplement parce que sur la première requête on fait une "action" sur tous les champ "date_du_message" parce qu'on lui ajoute un interval. ok. j'en déduis que ce que je fais est acceptable.
en revanche si jamais tu connais une ou deux fonctions qui traitent bien les dates en php, je suis preneur, j'ai regardé dans la doc php, mais rien trouvé d'équivalent.
edit end
sinon, perso. j'utilise cela en sql, principalement parce que je ne trouve pas de fonction php faisant l'équivalent de : DATE_SUB(NOW(), INTERVAL 20 MONTH)
doc pour les fonctions mysql sur les dates
SELECT monchamp FROM matable WHERE date<DATE_SUB(NOW(), INTERVAL 20 MONTH)
je n'ai pas compris la différence entre ta première requête et la seconde : ( désolé :? )
pas bien : WHERE date_du_message + INTERVAL 20 MONTH > NOW()
bien : WHERE date_du_message > NOW() - INTERVAL 20 MONTH
edit start
ok je vois.. 8)
simplement parce que sur la première requête on fait une "action" sur tous les champ "date_du_message" parce qu'on lui ajoute un interval. ok. j'en déduis que ce que je fais est acceptable.
en revanche si jamais tu connais une ou deux fonctions qui traitent bien les dates en php, je suis preneur, j'ai regardé dans la doc php, mais rien trouvé d'équivalent.
edit end
sinon, perso. j'utilise cela en sql, principalement parce que je ne trouve pas de fonction php faisant l'équivalent de : DATE_SUB(NOW(), INTERVAL 20 MONTH)
doc pour les fonctions mysql sur les dates
ok c'est bien ce qui me semblait.FlorentP a dit:En php, pour les dates c'est un peu "lourd", faut utilise date() et mktime(), c'est plus simple de gérer ça avec mysql en fait
il n'existe pas de fonctions équivalentes en php.
faut tout se faire avec le timestamp quoi..boef comme solution.
merci à toi FlorentP
Si tu t'en doutais pourquoi avoir dit
(/me se retiens de placer une petite boutade bien désagréable comme tu l'as fait dans ton message, boutade expliquant qu'en reflechissant 2 minutes tu aurais pu arriver a cette réponse comme un grand)
Pour passer tout simplement outre les limites du timestamp, il suffit de tout simplement ne pas utiliser de timestamp ... Genre 2005-10-03, -2000-10-03, etc ... enfin c'est la classe qui gère le bazard après.
Enfin si je répond au sujet à la base c'est pas pour répondre a ta mauvaise humeur, mais pour répondre a FlorentP. Je viens de regarder la classe Cache de phpBB, et apparament a chaque cache->get ils include() a nouveau le résultat de la requète ... forcément le benchmark en patie largement. En gardant en mémoire le résultat de la requète, les 1000 itérations n'auraient pas fait 1000 include(), ce qui aurait amélioré largement les performanances. Maintenant le cache aurait surement été un peu plus lent que le cache MySQL, mais l'écart aurait été largement moindre.
Sachant qu'une classe est une fonction équivalente ... alors avant de répondre en prenant le temps d'etre le plus désagréable possible, prend le temps de lire ma réponse.
(/me se retiens de placer une petite boutade bien désagréable comme tu l'as fait dans ton message, boutade expliquant qu'en reflechissant 2 minutes tu aurais pu arriver a cette réponse comme un grand)
Pour passer tout simplement outre les limites du timestamp, il suffit de tout simplement ne pas utiliser de timestamp ... Genre 2005-10-03, -2000-10-03, etc ... enfin c'est la classe qui gère le bazard après.
Enfin si je répond au sujet à la base c'est pas pour répondre a ta mauvaise humeur, mais pour répondre a FlorentP. Je viens de regarder la classe Cache de phpBB, et apparament a chaque cache->get ils include() a nouveau le résultat de la requète ... forcément le benchmark en patie largement. En gardant en mémoire le résultat de la requète, les 1000 itérations n'auraient pas fait 1000 include(), ce qui aurait amélioré largement les performanances. Maintenant le cache aurait surement été un peu plus lent que le cache MySQL, mais l'écart aurait été largement moindre.
8O est-ce que la classe est directement intégrée à PHP ?Genova a dit:
non, donc : il n'existe pas de fonctions équivalentes en php
ensuite je me doute qu'il existe déjà des scripts, mais alors pour ce qui est de trouver un script fiable, c'est autre chose...c'est le pourquoi de ma boutade, car tu le sais très bien ça...donc un ou deux liens indiquants des scripts fiables ne sont jamais de refus...
chose à laquel tu réponse gentiment:
lâche toi :wink:Genova a dit:
pour ce qui concerne cela:
je te l'accorde, remarque non pertinente :wink:thierry8 a dit:
Mais c'est normal de refaire l'include !Genova a dit:
En condition normale, l'include sera fait a chaque fois, sauf si ton soft est mal foutu et dans l'exécution d'une même page, exécute plusieurs fois la même requête !
Parceque sinon, de la même façon on a qu'a dire au benchmark de conserver le résultat de la requete dans une variable php et hop, le tour est réglé, ya plus rien qui ne diffère entre les deux tests...
Là le cache mysql il existe de façon persistante, il n'est pas lié à l'exécution de la page.
C'est à dire que si on faisait une page avec juste une seule fois la requete, lors de sa première exécution, ça mettrait disons 1 seconde, par contre si on fait un refresh de la page, le même bout de code ne mettra que 10 milli seconde, parceque mysql gère ça dans SA mémoire et non pas dans un truc lié à l'exécution de la première page.
Avec le cache php, lors d'un refresh, il faudra qu'il include le fichier.
Donc le bench représente bien ce qui se passe en réalité
Oui je suis d'accord bien sur. Dans ce cas en temps normal, sur deux - trois requètes, il n'y a aucune différence entre les deux cache tellement le temps d'execution sera insignifiant. La différence restera l'intérogation du serveur SQL au lieu du serveur du fichier suivant le cache, et pour un forum destiné à des particuliers et non a des grosses entreprises qui payent leur forum, ça peut jouer.
Ensuite si au lieu de stoquer le résultat des requètes dans un cache de fichier, mais dans un cache PHP comme eaccelerator, le résultat sera gardé aussi en persistance dans la mémoire. Bon malheuresement peu d'hébergeurs ont ce genre d'extensions installées ..
Ensuite si au lieu de stoquer le résultat des requètes dans un cache de fichier, mais dans un cache PHP comme eaccelerator, le résultat sera gardé aussi en persistance dans la mémoire. Bon malheuresement peu d'hébergeurs ont ce genre d'extensions installées ..
je peux te presenter mon script de forum:AllM a dit:
http://www.fast-board.com
Il est pas encore en distribution mais bientot, peut etre qu'il pourra t'interesser.
forummp3 a dit:
Oui j'avais vu ça, faut que je regarde en détail
En fait je suis de plus en en plus en train de m'orienter vers IPB, qui semble très puissant et rapide. En plus je vois qu'il propose un composant blog qui m'intéresse pas mal.
Phpbb3 faut que je creuse, mais je suis pour l'instant un peu déçu de phpbb, à cause de la v2.
Allons faire un tour...
Il existe un comparateur en ligne de scripts de forum:
http://www.forummatrix.org/
C'est assez bien fait, apparemment mis à jour régulièrement, et plutôt lisible !
Ca reste néanmoins un comparateur "sur le papier" et ne vaudra jamais les retours d'expériences
Il existe un comparateur en ligne de scripts de forum:
http://www.forummatrix.org/
C'est assez bien fait, apparemment mis à jour régulièrement, et plutôt lisible !
Ca reste néanmoins un comparateur "sur le papier" et ne vaudra jamais les retours d'expériences
Bonjour tout le monde
Je remonte ce petit topic intéressant pour vous présenter mon script de forum, qui est sortit officiellement depuis 2 mois environ (1 juillet 2009):
http://www.faboard.fr
Il est :
-rapide
-puissant
-sécurisé
-simple d'utilisation
Vous pouvez le tester à cette adresse:
http://www.faboard.fr/forum_demo/
login: test
mot de passe: test
Si vous avez des questions n'hesitez pas !
Si vous connaissez des webmasters qui cherchent un forum, n'hesitez pas à leur parler de faboard !
Je remonte ce petit topic intéressant pour vous présenter mon script de forum, qui est sortit officiellement depuis 2 mois environ (1 juillet 2009):
http://www.faboard.fr
Il est :
-rapide
-puissant
-sécurisé
-simple d'utilisation
Vous pouvez le tester à cette adresse:
http://www.faboard.fr/forum_demo/
login: test
mot de passe: test
Si vous avez des questions n'hesitez pas !
Si vous connaissez des webmasters qui cherchent un forum, n'hesitez pas à leur parler de faboard !
Discussions similaires
