Quel script de forum choisir ?

colonies a écrit:

thierry8 a écrit:pour ce qui est gourmandise, le truc c'est que.., en partant du principe que c'est bien codé, c'est que seul une gestion cache via fichiers peut être intéressante

Mais pas vraiment possible puisque chacun voit quelque chose de différent. Sur mes posts, je vois une option d'édition... par exemple. Sur la home, les forums où il y a des topics que JE n'ai pas lus ont une image différente. Etc, etc.

C'est tout à fait possible. C'est un gros boulot, mais faisable !

Albert1 a écrit:

colonies a écrit:P|-|PBB3 intègre un cache de template, c'est déjà un plus, il évite une étape de parsing. Je ne sais pas ce que font les autres.

c'est déjà possible depuis fort longtemps avec la 2 ... et quand on parle de SQL, c'est un peu HS, mais bon, comme dirait Coubertin

alors il faut parler de quoi, hormis SQL ?

ajax>ben tu remarqueras que c'est plus la commande site: de google qui merde qu'autre chose .

Pour vB : http://www.vbseo.com/

WRI>si par hasard tu as l'intention de changer le forum (on ne sait jamais :p), MesDiscussions ça poutrerait :p (je tente :p, surtout que IDN y est passé je crois, par contre pour migrer c'est chaud :p).

colonies a écrit:ajax> je sais, mais si tu as bien suivi l'histoire, tu verrais qu'on n'est plus du tout dans la même situation qu'avant.
La beta en est la preuve (une vraie bêta, hein), et tu as accès aux commit du CVS pour voir qu'ils s'activent, et ce depuis plusieurs mois, que l'équipe a grossi...
Regarde donc ça :
http://area51.phpbb.com/statcvs/

Et puis ils ont déjà expliqué ce qui s'était passé. Bon...

J'aime bien, même beaucoup phpbb, mais franchement, depuis que je suis passé sous SMF, c'est les vacances et mon serveur respire mieux (pas encore bien car smf est assez gourmand).

thierry8 a écrit:

colonies a écrit:

thierry8 a écrit:pour ce qui est gourmandise, le truc c'est que.., en partant du principe que c'est bien codé, c'est que seul une gestion cache via fichiers peut être intéressante

Mais pas vraiment possible puisque chacun voit quelque chose de différent. Sur mes posts, je vois une option d'édition... par exemple. Sur la home, les forums où il y a des topics que JE n'ai pas lus ont une image différente. Etc, etc.

C'est tout à fait possible. C'est un gros boulot, mais faisable !

Mais qu'est-ce que tu veux mettre en cache au juste ? tu imagines l'espace disque que ça prendrait ? et sinon, le niveau d'explosion de chaque page en de multiples fichiers ?
tu devras faire un gros travail pour leur gestion, les assembler et au final, la sélection des fragments et les accès disques seront très probablement plus lents que sans cache. N'oublie pas que sur un phpbb, même les visiteurs voient un status différent des threads vus et non vus.

bah non... il suffit de mettre en cache la version destinée aux visiteurs (non membres), cad 90% des accès au serveur sur la plupart des forums.
Sur WRI et avec l'aide de fandeciné ceci est en préparation depuis des mois, mais j'ai jamais eu le courage de finir. Ca viendra un jour !

Je note donc que vBulletin pourrait être bien, surtout vbseo semble impeccable. Egalement SMF semble bien mais on n'a pas assez d'avis encore.

wullon a écrit:MesDiscussions ça poutrerait :p (je tente :p, surtout que IDN y est passé je crois, par contre pour migrer c'est chaud :p).

La migration n'a rien de chaud c'est mesdiscussions qui s'en charge
Dans le cas de IDN, petit truc "sympa" pour une migration : le format des urls du forum n'ont pas changées... donc au niveau référencement, c'est totalement transparent

Si je comprends ou - ou dites moi si je me trompe - pour vbseo, il faut d'abord ajouter le cout de la licence + le soft de rewriting de vbseo ?

y a t-il une norme bbcode ?

parce que pour les migrations, ça serait plus simple.
(si vous avez des liens je suis preneur)

colonies a écrit:Mais qu'est-ce que tu veux mettre en cache au juste ? tu imagines l'espace disque que ça prendrait ? et sinon, le niveau d'explosion de chaque page en de multiples fichiers ?
tu devras faire un gros travail pour leur gestion, les assembler et au final, la sélection des fragments et les accès disques seront très probablement plus lents que sans cache. N'oublie pas que sur un phpbb, même les visiteurs voient un status différent des threads vus et non vus.

l'accès lecture fichier est bien plus rapide que des reqûetes, et bien moins gourmand en mémoire.....pas pour rien que PHP6 s'oriente avec leur nouveau système de stockage : SQLite

et comme il y a au moins 90% de lecture par rapport à des écritures, ça tombe bien.

le système "fichier" et le plus adapté au web !

Après j'ai pas dis que c'était facile à mettre en place, hein
Faut savoir ce que l'on veut c'est tout, mais le résultat est garantie, si le développement n'est pas baclé!

Seul inconvénient comme, je l'avais effectivement dis: l'espace disque.
(mais aujourd'hui, c'est l'un des problèmes qui ce règle le plus facilement!)

WebRankInfo a écrit:bah non... il suffit de mettre en cache la version destinée aux visiteurs (non membres), cad 90% des accès au serveur sur la plupart des forums.
Sur WRI et avec l'aide de fandeciné ceci est en préparation depuis des mois, mais j'ai jamais eu le courage de finir. Ca viendra un jour !

Tu vas gagner en vitesse, mais il y a vraiment pas mal de choses à prendre en compte, les templates doivent être modifiés, et pour les mises à jour c'est assez moyen.
Le genre de raison qui me retiennent : il y a pas mal d'infos dynamiques pour chaque post :
Le nombre de posts total d'un membre... Par exemple, toi tu as plus de 11000 posts : si tu devais altérer toutes les pages en cache pour que ce compteur reflète encore ton nombre de posts en temps réel... ouille !
Quelqu'un vire ou modifie son www -> toutes les pages où il a posté doivent être altérées. Eventuellement s'il déménage ("Localisation").
Un changement d'avatar -> idem. Passage à un autre rang -> Pareil.
Tu utilises les sid pour les visiteurs sans cookies -> c'est perdu (mais ça c'est pas très grave)

Bref, ça fait beaucoup de facteurs. C'est vrai que le principal est dans le contenu des messages et que c'est pas si grave de ne pas refléter l'état réel de la base pour les visiteurs de passage, mais tout de même.

thierry8 a écrit:pas pour rien que PHP6 s'oriente avec leur nouveau système de stockage : SQLite

c'est déjà le cas avec php5, mais les raisons de ce choix sont plus complexes, ça n'est pas qu'une histoire de performances.

le système "fichier" et le plus adapté au web !

ah bon. je vais répondre en argumentant tout autant : rien ne remplacera une base SQL classique.

Enfin bref, ce ne sont pas de bons arguments. De toute façon, MySQL stocke aussi ses données dans des fichiers, et SQLite stocke bien ses les résultats en mémoire avant de te les retourner
De plus, l'efficacité d'une base est quasiment toujours fonction d'un projet, il n'y a pas de vérité absolue dans ce domaine, entrent en jeu : le moteur SQL, l'optimisation des requêtes, le système de cache... enfin bref, beaucoup de choses.

Par exemple, si tu as un forum énorme mais que les seuls les 100 derniers posts génèrent 50% du traffic, ton cache peut avoir tous les résultats et les servir en un clin d'oeil. Pour un chat, une table MEMORY de MySQL a aussi des performances très satisfaisantes.

Bon, et même, regarde les benchs sur le site de SQLite :

SELECT avec index :
MySQL: 1.270
SQLite 2.7.6: 1.121
SQLite 2.7.6 (nosync): 1.162

Ouuuuh, quel gain énorme ! Commentaire :
All three database engines run faster when they have indices to work with. But SQLite is still the fastest.

En INSERT non indexé :
MySQL: 0.114
SQLite 2.7.6: 13.061
SQLite 2.7.6 (nosync): 0.223
Commentaire : In spite of this, the asynchronous version of SQLite is still nearly as fast as MySQL.

Mort de rire. Dans le premier cas, on rappelle bien qui est le plus rapide (de peu) et dans le deuxième... "presque aussi rapide que MySQL". Deux fois plus lent, oui.

Bref, les chiffres, hein...

colonies a écrit:

thierry8 a écrit:pas pour rien que PHP6 s'oriente avec leur nouveau système de stockage : SQLite

c'est déjà le cas avec php5, mais les raisons de ce choix sont plus complexes, ça n'est pas qu'une histoire de performances.

oui enfin PHP 5, c'est le transitionnel...donc je n'en ai pas fait référence.
et pour te répondre: oui évidemment que ce ne sont pas les seules raisons.

colonies a écrit:

le système "fichier" et le plus adapté au web !

ah bon. je vais répondre en argumentant tout autant : rien ne remplacera une base SQL classique.

Enfin bref, ce ne sont pas de bons arguments.

Je n'ai pas vu d'argument encore ?

colonies a écrit:De toute façon, MySQL stocke aussi ses données dans des fichiers, et SQLite stocke bien ses les résultats en mémoire avant de te les retourner

C'était de l'humour, n'est-ce pas ?

colonies a écrit:De plus, l'efficacité d'une base est quasiment toujours fonction d'un projet, il n'y a pas de vérité absolue dans ce domaine, entrent en jeu : le moteur SQL, l'optimisation des requêtes, le système de cache... enfin bref, beaucoup de choses.

On est d'accord, je n'ai encore jamais prétendu le contraire.

colonies a écrit:Par exemple, si tu as un forum énorme mais que les seuls les 100 derniers posts génèrent 50% du traffic, ton cache peut avoir tous les résultats et les servir en un clin d'oeil. Pour un chat, une table MEMORY de MySQL a aussi des performances très satisfaisantes.

? ? ? ? ?

colonies a écrit:Bon, et même, regarde les benchs sur le site de SQLite :

SELECT avec index :
MySQL: 1.270
SQLite 2.7.6: 1.121
SQLite 2.7.6 (nosync): 1.162

Ouuuuh, quel gain énorme ! Commentaire :
All three database engines run faster when they have indices to work with. But SQLite is still the fastest.

En INSERT non indexé :
MySQL: 0.114
SQLite 2.7.6: 13.061
SQLite 2.7.6 (nosync): 0.223
Commentaire : In spite of this, the asynchronous version of SQLite is still nearly as fast as MySQL.

Mort de rire. Dans le premier cas, on rappelle bien qui est le plus rapide (de peu) et dans le deuxième... "presque aussi rapide que MySQL". Deux fois plus lent, oui.

Bref, les chiffres, hein...

..ben oui...les chiffres hein...sans les sources et savoir sur quoi est basé le test, évidemment ça change la donne..

C'était de l'humour, n'est-ce pas ?

sans les sources et savoir sur quoi est basé le test, évidemment ça change la donne..

sur le site de SQLite. tu me cites en plus

en home, le lien "faster" : http://www.sqlite.org/speed.html

Edit : en fait, c'est ton "gain en mémoire" du post précédent qui me fait tiquer. si elle est bien exploitée, ça permet justement d'aller bien plus vite puisqu'un accès disque est toujours bien, bien plus lent qu'un accès ram. d'où mon exemple de contenu le plus utilisé conservé (l'histoire des 100 posts) en cache.

FlorentP a écrit:

wullon a écrit:MesDiscussions ça poutrerait :p (je tente :p, surtout que IDN y est passé je crois, par contre pour migrer c'est chaud :p).

La migration n'a rien de chaud c'est mesdiscussions qui s'en charge
Dans le cas de IDN, petit truc "sympa" pour une migration : le format des urls du forum n'ont pas changées... donc au niveau référencement, c'est totalement transparent

Justement, pour la migration, il me semble qu'il y avait eu quelques soucis sur IDN (profils membres notamment).

Mais tu dois mieux connaître MD que moi (puisque tu l'utilises en tant qu'admin on dirait ), donc je te crois volontier .

Je crois que la grosse force de MD, c'est l'optimisation de la charge serveur. Je crois que les gros gros forums, comme celui de Hardware, utilisent MD notamment pr ça (ça réduit les coûts d'hébergement !).

Par contre, je crois que le personnalisation du code est plus compliquée que ce qu'on peut avoir sur d'autres scripts. Je ne sais pas si tout est open source d'ailleurs sur MD ?


Pr ce qui concerne l'indexation Google des url d'un forum SMF... je n'arrive pas bien à voir qu'est-ce qui pourrait bloquer ??? Si qqn voit des trucs à corriger dans le code je suis preneur !