Bonjour à tous,

Nous envisageons (c'est même du quasi certain lol) d'utiliser FSB2 pour un gros forum.

j'aimerais savoir si l'équipe possède un script de test de montée en charge, j'aimerais voir comment se comporte le forum sur 300 ou 400 connexions simulatanées. Côté serveurs pas de soucis, mais actuellement, nous sommes sous phpBB2 et c'est un gros problème (Too many connections etc...).

En tout cas, je suis complètement accro lol

Ah oui, le Wysiwyg en onglet c'est un mod ?

Merci d'avance

Pour le Wysiwyg non ce n'est pas un mod, c'est juste la prochaine version en avant première ici ^^

Pour le test de montée en charge je ne sais pas par contre :\

pour fsb1 un script avait été fait, pour fsb2 non.

donc il reste à le faire.

Merci pour vos réponses

Par contre, je n'ai pas trouver le script pour FSB1, Grummfy, si tu peux me dire où le trouver, je verrais si je peux l'adapter à la V2 !

++

J'vais surement dire une connerie, mais je comprends pas trop ce que tu veux tester...

LE fait qu'il y ait trop de connections est censé être inhérant au nombre de visiteurs, donc la charge du serveur, non ?

Si je me trompe pas, ça te sers à rien de tester quoique ce soit, faut juste redimensioner ton serveur, ou réduire la consommation en requêtes/connexions, et alors c'est le nombre de requêtes moyennes envoyées par le forum qui est à prendre en compte (et sur ce point FSB2 de base n'envoie pas beaucoup moins de requêtes, mais comme y'a le cache, ça devient TRES intéressant (et puis certaines requêtes sont drastiquement optimisées))

Pareil, je ne l'ai pas retrouver. Mais que veux tu exactement tester ? Stresser le nombre d'utilisateurs enregistrés, le nombre de messages/sujets ? Pcq si c'est juste le nombre de personnes connectés en meme temps je ne vois pas le besoin que ce soit adapté à un script en particulier puisque ce sont juste des connexions que l'on peut faire via cURL.

Ok, je vois que quelques précisions s'imposent Lol

Nous avons aujourd'hui 100 000 inscrits sur le forum. Cela génère une activité non négligeable, vous l'imaginez facilement.

A l'heure actuelle, nos serveurs ne sont pas du tout surchargés en terme de CPU, mémoire ou disques. Les seuls soucis que nous rencontront sont inhérants au nombre de connexions/requêtes simultanées générées par PhpBB rendant le forum inaccessible par moment, voire mettant la base mysql en protection.

L'equipe aimerait simuler cette activité pour voir le comportement du forum mais également la réaction de nos serveurs.

Merci de votre aide

Cela dépends du temps que prennent tes requêtes mais aussi de la quatités, or fsb 2 via son système de cache demande moins de requêtes et semble plus rapide.


Certes sans test on peux rien te garantir, mais en principe cela devrait aller mieux.

Pour info, c'était burster qui avait fait le script

oui mais là c'est un stress du nombre d'utilisateurs et du nombre de messages pas des connexions simultannées. Il s'agirait plutot d'un script qui effectuerait des requetes cURL en masse.

Merci pour vos réponses.

Bon on est tous accro à FSB pour le moment, donc on va tenter le coup je pense. En mettant le nez dans le code, on voit nettement que les requêtes sont plus optimisées que dans PhpBB.

L'idée des requêtes à l'aide de cURL est une bonne idée, si j'ai un peu de temps je me pencherais sur la question.

Merci encore

++

vous hébergés sur quelle structure avec ces 10000 inscrits, sur un mutualisé, un dédié, un dédié virtuel ?

Avec notre site, on vient de passer sur un dédié virtuel car on avait trop de problèmes sql, aujourd'hui les forums sont une vraie bombe, je n'ai jamais vu des pages s'afficher aussi rapidement.

Ah mon avis il a un dédié, si ce n'est plusieurs avec redondance

Justement ca c'est mal. L'intérêt d'avoir plusieurs dédiés est justement qu'en cas de coupure, il faut pouvoir, avec la sauvegarde des données de l'un sur l'autre, basculer directement sur le serveur de secours.
Ensuite, un dédié pour le serveur http et un dédié pour le serveur sql, les deux problèmes sont que, l'un demande surtout du processeur, et l'autre de l'accès disque, donc on n'optimise pas du tout les performances en les plaçant sur deux serveurs différents, et enfin, si tu es obligé de passer par le réseau pour faire une requète sql, c'est plus long que de le faire en local.