Yes, et comme tu le sais, je viens seulement de m'occuper du référencement avec un point de détail important que j'avais négligé.
En prime on a changé de nom de domaine donc le référencement a recommencé à zero en aout.
Mais le plus important, quels que soient les moyens mis en oeuvre pour celui ci reste le contenu!
La question que l'on pourrait se poser est de savoir si SMF a un moteur capable de gérer un très grand nombre d'utilisateurs?
Aucun SMF dans le lien que j'ai donné dans le premier message sur les plus gros Forum du monde.
Le premier utilise un Phpbb mais qui a été complètement reconstruit par une équipe de pro et qui n'a plus comme rapport avec Phpbb que le nom. En fait, passé un certain cap en nombre de connectés simultanés, de messages, quel que soit le forum il est nécessaire d'adapter le code. Et de toute façon il faut plusieurs serveurs dédiés pour tenir le choc. ( 80 pour l'espèce de godzilla qui détiend le record, ça fout vraiment le vertige)
Concernant SMF, oui, il a été conçu pour pouvoir gérer un nombre énorme de membres/messages et autres.
Une fois passé les 50 000 messages je pourrais créer un index personnalisé par l'administration pour que le moteur de recherche puisse suivre. Et il y a trois paliers pour cet index (qui fait grossier passablement la taille de la base de donnée): petit, moyen et grand.
Ensuite le problème est plus une question de ressources que de moteur de site.
Par exemple, et pour bien confirmer que tout est prévu, dans l'administration on peut aussi voir que l'on peut utiliser les systèmes de cache suivants:
* APC
* eAccelerator
* Turck MMCache
* Memcached
* Zend Platform/Performance Suite (pas Zend Optimizer)
Bien entendu, nous n'avons pas de système de ce genre sur un hébergement mutualisé.
A savoir que par exemple, Turck MMCache est le système utilisé par Wikipédia qui est un autre genre de monstre en terme d'utilisateurs constants et de ressources nécessaires, n'oublions pas qu'il est internationale.
Ensuite, un autre problème se pose, les requêtes.
Un serveur SQL a une tolérance sur le nombre de connections simultanées. On parle en fait de requêtes en "entrée sorties", et par exemple ici nous avons droit à 10 connections simultanées ce qui représente plusieurs centaines de membres qui seraient connectés en même temps. Du moins c'est théorique et relatif, en effet, tout dépend de ce que le webmaster a voulu.
Par exemple, en diminuant les fonctionnalités, la génération d'une page nécessite moins de requêtes. Et les gros forum ne peuvent se permettrent le luxe d'un nombre élevé.
Souvent on voit que le moteur de recherche est limité en nombre de lettre minimum, qu'il est inaccessible aux invités, et l'aspect général est souvent fruste.
Ici nous n'y allons pas avec le dos de la cuiller, il faut jusqu'à 40 requêtes pour générer une page.
Un autre facteur est important. Il faut que les deux serveurs, SQL et le serveur de fichier soient performants de façon égales.
Lorsque nous étions chez Easygiga, les performances étaient au maximum et il fallait presque 2X moins de temps pour générer une page. Il semble qu'ici ce soit le serveur SQL qui est le maillon faible. Mais il subit des perturbations actuellement, espérons que les choses s'améliorent.
Maintenant regardons les stats du forum Officiel de SMF qui est assez monstrueux en terme de nombre d'utilisateurs.
On est pas loin du double de Ubuntu.fr. Cependant il y a moins de membres connectés simultanément, autre paramètre important. Mais les bases de données doivent atteindre des tailles impressionnantes.
On peut voir l'ip du serveur sous ces stats (désolé, pas dans la capture, mais le lien est
http://www.simplemachines.org/community/index.php?action=stats ) En effet, il faut plusieurs serveur à ce stade. J'en ai comptabilisé au moins 2.
Et puis vous allez me dire, la c'est SMF2. Oui mais il y a quelques semaines c'était encore SMF 1.1.5. Et ça fonctionnait aussi bien, voir mieux vu que ce n'était pas une bêta. La conversion vers SMF2 n'a pas posé de problème malgré les tailles énormes des bases. (je parle de conversion car au passage d'une nouvelle version / branche, le mot mise à jour n'est plus exact)
On remarque aussi qu'en allant à l'index de ce forum, il ne faut que 8 requêtes pour générer une page.
Page created in 0.563 seconds with 8 queries.
Page served by: 207.210.95.108
Et nous:
Page générée en 0.302 secondes avec 27 requêtes. (Pretty URLs adds 0.037s, 1q)
(Sur notre premier hébergement c'était 0.160 secondes avec 27 requêtes)
J'ai déjà vu des sites avec plus de 100 requêtes pour générer une page rester extrêmement rapides, avec un petit nombre de membres/utilisateurs mais surtout des serveurs vraiment au top.
Donc être petit a des avantages, on peut se permettre beaucoup de luxe et ne limiter que peu de choses ou rien.
Avoir beaucoup de membres est sympa et justifie les efforts fournis, mais en avoir un grand nombre connectés simultanément et qui de plus postent pleins de messages devient un gros casse tête, en ressources humaines, matériels et moyens comme en modération et capacités de support.
Notre fonction est plus une base de donnée documentaire et de ressources que de support, on peut donc penser que nous pourrions avoir dans le futur un grand nombre de membres avec une participation qui resterait faible, toutes proportions gardées, ce n'est pas un mal.
Nos stats rien qu'à nous sont visibles ici: (le lien est dans le bas de page à l'index du forum)
http://passion-xbmc.org/stats/Et pour info, les stats de téléchargement sont visibles ici:
http://passion-xbmc.org/tpmod/?dl=stats (l'url rewriting n'est pas encore geré pour le portail et ses modules, ça viendra)
Vie du Site
Réponse Rapide
