Bonjour,
Je souhaiterais avoir des retours sur les configurations matérielles de serveurs Moodle dans des Universités .
A Caen, nous avons environ 20000 utilisateurs potentiels (étudiants +enseignants). La plate-forme est mise en production à la rentrée d'octobre et quelques inquiétudes se profilent par rapport à une éventuelle pandémie.De plus l'intégration et la généralisation du C2I sur cette plate-forme vont aussi augmenter la charge.
J'ai transmis la documentation au CRI mais j'aimerai avoir quelques retours supplémentaires pour étayer mon argumentation (load balancing, capacité de disque par exemple)
Merci
Bonjour,
je sais que Moodle peut supporter plus de 20000 étudiants.
En terme de serveur, il est conseillé d'utiliser le système Debian GNU/Linux, avec configuration du serveur Apache et d'une base de données MySQL ou PostgreSQL.
Il faut également s'assurer d'une bonne bande passante, en particulier pour les possibles connexions simultanées.
Jérémie
je sais que Moodle peut supporter plus de 20000 étudiants.
En terme de serveur, il est conseillé d'utiliser le système Debian GNU/Linux, avec configuration du serveur Apache et d'une base de données MySQL ou PostgreSQL.
Il faut également s'assurer d'une bonne bande passante, en particulier pour les possibles connexions simultanées.
Jérémie
Merci Jérémie,
En fait nous avons déjà cette configuration avec un serveur Mysqll séparé. Ma question concerne plutôt la monté en charge avec beaucoup de connexions simultanées.
En fait nous avons déjà cette configuration avec un serveur Mysqll séparé. Ma question concerne plutôt la monté en charge avec beaucoup de connexions simultanées.
ok,
dans ce cas, il faut que le service informatique s'assure d'un bonne bande passante (1Gbps) et de la mémoire vive (>4GB)
Jérémie
dans ce cas, il faut que le service informatique s'assure d'un bonne bande passante (1Gbps) et de la mémoire vive (>4GB)
Jérémie
Cela ne suffira pas...
Il est essentiel de configurer correctement son serveur MySQL. Les connections simultanées génèrent grosso modo entre une et deux connexions à la base (suivant qu'il y a des sous-requêtes ou des redirections).
Mysql à un certain nombre de paramètres importants :
Nombre max de requêtes admises,
Taille des buffers de threads,
Mémoire allouée aux buffers de threads,
Mémoire allouée aux tables d'indexes
Il existe des règles de calcul dans la doc mysql pour régler ces paramètres qui déterminent la puissance nette de la base. S'ils ne sont pas réglés, Mysql marchera avec la config de base qui n'utilisera pas la mémoire qu'il devrait pouvoir obtenir du serveur.
Question Load Balancing, nous avons utilisé pour Pairformance un HAProxy avec succès sur 3 frontaux calibrés pour 400.000 comptes (montée en charge réussie et mesurée pour 1450 utilisateurs simultanés exécutaént des scénarios de navigation "connecté" dans les volumes de cours). Temps max de réponse ; 1/2 seconde. Notre calcul dit qu'une charge de 2500 simultanée doit être atteignable en réalité (moins systématique que les robots de test). Ceci évidemment hors déclenchement d'opérations très lourdes d'administration tels que des backups).
Cheers.
Merci Valery pour ces précisions,
Pour le serveur Mysql de notre Université, la configuration est OK
Pour le Load Balancing, si tu as des précisions supplémentaires sur votre architecture qui me semble être celle sur laquelle nous allons nous orienter.
Cordialement,
Pour le serveur Mysql de notre Université, la configuration est OK
Pour le Load Balancing, si tu as des précisions supplémentaires sur votre architecture qui me semble être celle sur laquelle nous allons nous orienter.
Cordialement,
Bonjour,
HAproxy gère la répartition de charge http entre différentes instances de moodle.
Comment faites-vous pour l'accès aux documents ? Ceux-ci sont enregistrés sur le file-système, il faut donc que chaque instance y ait accès.
un partage nfs ou quelque chose du genre ?
Vincent
HAproxy gère la répartition de charge http entre différentes instances de moodle.
Comment faites-vous pour l'accès aux documents ? Ceux-ci sont enregistrés sur le file-système, il faut donc que chaque instance y ait accès.
un partage nfs ou quelque chose du genre ?
Vincent
Bonjour Vincent,
je ne suis pas le spécialiste côté système mais je peux te dire l'architecture choisit et en place.
- 3 Frontaux APACHE
- cluster php composé de 3 serveurs
- cluster serveur mysql 2 serveurs
- montage NFS de ces 3 serveurs php vers un serveur de stockage.
Charles
je ne suis pas le spécialiste côté système mais je peux te dire l'architecture choisit et en place.
- 3 Frontaux APACHE
- cluster php composé de 3 serveurs
- cluster serveur mysql 2 serveurs
- montage NFS de ces 3 serveurs php vers un serveur de stockage.
Charles
Bonjour,
j'aurai voulu savoir comment vous avez mis en place cette architecture.
il nous est demandé de faire de même à l'Université de Bourgogne.
merci
j'aurai voulu savoir comment vous avez mis en place cette architecture.
il nous est demandé de faire de même à l'Université de Bourgogne.
merci
Ca y est , ma plate-forme est en production avec l'architecture suivante pour de la haute disponibilité, mise en place par le CRI de notre université.
La bande passante ne pose pas de soucis actuellement.
En cas de pandémie ou de blocage (notre université compte environ 28000 étudiants), le CRI m'assure que cela devrait tenir, je fait donc confiance aux spécialistes.
Si cela peut aider ...
1. Architecture matérielle (RAM, CPU)
Les serveurs physiques disposent actuellement de 4 à 8 Go de RAM et les processeurs sont des bi-proc quad-core à 3 Ghz.
Ces caractéristiques répondent largement aux préconisations de Moodle.
2. Répartition de charge (CPU, réseau)
Le CRISI utilise deux plateformes de répartition de charge pour assurer la haute disponibilité (continuité de service) et la répartition de charge (load balancing) nécessaire au fonctionnement de nombreux services. C'est notamment le cas pour les serveurs web.
Les plate-formes de répartition de charge utilisent des serveurs physiques (hôtes) sur lesquelles fonctionnent des serveurs logiques (vservers LVS ).
Plusieurs serveurs virtuels concourent à la répartition de charge et à la haute disponbilité d'un même service.
Ex : les requêtes adressées au service web sont prises en charge par 3 reverses-proxies puis vers 2 serveurs Apache.
3. Serveur de base de données adapté
Actuellement le serveur de base de données fonctionne en haute disponibilité (serveur redondé et basculement automatique du service Mysql vers un serveur de secours).
La configuration du serveur a été adaptée (RAM et optimisation de la configuration Mysql notamment).
4. Capacité de stockage et de sauvegarde adaptée
Toutes les données (vservers, services et données utilisateurs) sont stockées sur les filers dont la volumétrie est extensible dans la limite des disques disponibles et des capacités d'extension des filers de production et de sauvegarde.
Les filers de production utilisent des disques FC (rapide).
Les sauvegardes sont effectuées sur disque (filer) et sur bande pour les rétentions les plus importantes.
5. Optimisation des configurations Service (Apache/Php) et application (Moodle)
L'optimisation des configurations Apache, PHP et Moodle (gérées par moi-même) ne pose pas de soucis dans la mesure ou ces applications sont dédiées à un seul et même service (pas d'interdépendance).
Les débits réseau d'accès aux disques des filers depuis les serveurs sont surveillés.La bande passante ne pose pas de soucis actuellement.
En cas de pandémie ou de blocage (notre université compte environ 28000 étudiants), le CRI m'assure que cela devrait tenir, je fait donc confiance aux spécialistes.
Si cela peut aider ...
Excellente présentation !!
Nous avons à Toulouse du revoir également les paramètres du montage NFS. Notre premier montage générait des lourdeurs horribles d'accès aux fichiers, notemment au source de Moodle placés en partagé. Nous avons notamment viré la vérification de l'interblocage de partage, et revu la taille des transferts unitaires. Perfs x 30.
Nous avons observé une perte d'environ 15% entre disposer des fichiers php sur des disques locaux ou les avoir sur le volume partagé. Mais pour la maintenance du code, on a largement préféré le partagé.
Si je peux donner votre contact à Toulouse, ça nous intéresse pour mettre en place la réplication Mysql pour Pairformance. (on a essayé en ndbcluster, une horreur...).
Selon mes calculs, vous devriez tenir au minimum de 2500 consultations simultanées sans problème, soit environ 10.000 à 12.000 utilisateurs loggués.
Cheers.
Bonjour,
Je n'ai fait que présenter l'excellent travail effectué par le CRISI de l'UCBN mais qui me semblait vraiment intéressant pour la communauté . C'est vrai que le montage qui m'a été proposé me permet une maintenance du code plutôt aisée.
Cela ne fait que 2 jours que tout est terminé, je n'observe aucune lenteur voire une amélioration mais je n'ai pas encore beaucoup d'utilisateurs connectés ensembles ( au plus 40 hier)
Par contre pour Mysql, il est seulement redondé et il n'y a pas de vraie répartition de charge type Mysq-Cluster (apparement cela pose pas mal de problèmes).
Concernant les calculs, merci mais je crois que c'est aussi à l'usage, en surveillant de près la charge ( ce qui m'inquiète c'est par exemple un téléchargement simultané de gros fichier , vidéos par exemple) que nous allons devoir nous adapter et aussi faire pas mal d'accompagnement des enseignants (des cours podcastés plutôt que des visios par exemple).
Bonne journée
Je n'ai fait que présenter l'excellent travail effectué par le CRISI de l'UCBN mais qui me semblait vraiment intéressant pour la communauté . C'est vrai que le montage qui m'a été proposé me permet une maintenance du code plutôt aisée.
Cela ne fait que 2 jours que tout est terminé, je n'observe aucune lenteur voire une amélioration mais je n'ai pas encore beaucoup d'utilisateurs connectés ensembles ( au plus 40 hier)
Par contre pour Mysql, il est seulement redondé et il n'y a pas de vraie répartition de charge type Mysq-Cluster (apparement cela pose pas mal de problèmes).
Concernant les calculs, merci mais je crois que c'est aussi à l'usage, en surveillant de près la charge ( ce qui m'inquiète c'est par exemple un téléchargement simultané de gros fichier , vidéos par exemple) que nous allons devoir nous adapter et aussi faire pas mal d'accompagnement des enseignants (des cours podcastés plutôt que des visios par exemple).
Bonne journée
Bonjour,
De notre coté, nous avons mis en place Moodle en production cette année et nous avons rencontré des ralentissements juste avant les examens.
* Configuration actuelle *
- Serveur Web
MAC Xserve 2xG5/2.33 GHz
2 Go RAM
Disques SATA en RAID 1 logiciel
Apache2, PHP5, Moodle 1.9.8
- Serveur BD
MAC Xserve 2xXeon 2.0 GHz Dual Core Xeon 5130 (64 bits)
3 Go RAM
1 To SATA drives RAID 1
MYSQL 5
Les 2 serveurs ne servent pas que Moodle (autres sites, autres bases).
* Statistiques relevés *
Nombre total d'utilisateurs Moodle : 4500
Nombre d'enseignants Moodle : 100
Nous avons en moyenne 7/800 visites par jour (stats Piwik, "installé" uniquement sur la page d'accueil)
Au moment des ralentissements :
-> 1900 visites / jour (stats piwik)
-> 163 visites / heure (stats piwik)
-> ~70 visiteurs dans les 5 dernières minutes (logs moodle)
-> 16220 nb d'actions / jour (logs moodle : http://moodle.xx/course/report/log/index.php)
* Projection *
L'année prochaine, nous allons étendre Moodle aux 35000 utilisateurs potentiels.
Mais ces 35000 utilisateurs potentiels utilisent déjà les autres plate-formes que Moodle va remplacer, nous avons donc les statistiques de cette année. Nous nous attendons à avoir, au moins :
- en moyenne 1400 visites par jour ("visites" de la page d'accueil)
- 3300 visites / jour (stats piwik) en pointe
Bref les connexions devraient doubler mais nous nous attendons à une augmentation supplémentaire notamment avec l'élargissement du C2i.
* Configuration prochaine *
Nous pensons conserver notre serveur de base de données et, dès la fin du mois, nous allons changer le serveur web pour un serveur Supermicro :
2x INTEL XEON L5506 (Quad-core) 2.90 Ghz (~)
8Go DDR3 RAM
Seagate Barracuda 7200.11 SATA-300-7200trs/m-32 Mo (RAID 5 hard)
Avec Ubuntu 10.04, PHP5, Apache2, APC, Moodle 1.9.8
** Questions **
Nous sommes en phase de test de montée en charge. Je viens donc à la recherche d'informations sur le dimensionnement de configurations déjà en place relatives aux nombres d'utilisateurs. Et je viens aussi à la recherche d'informations sur la manière de pratiquer des tests de montée en charge.
J'ai bien conscience que les réponses sur ce sujet sont souvent difficiles à donner et dépendent beaucoup de l'environnement, cependant, j'ai qq questions précises suite à ce que j'ai lues, et qq questions générales.
Pour ceux qui ont déjà mis en place des serveurs en production (je pense notamment à Anne Remy ou à Valéry Fremaux qui se sont exprimés ici) :
- comment avez-vous estimé votre nombre d'utilisateurs simultanés ? par rapport à des stats observés ? au nombre d'utilisateurs potentiels ?
Pouvez-vous donner aujourd'hui le rapport nombre d'utilisateurs potentiels/loggués/simultanés ? (même si je comprends qu'ils dépendent de bcp de choses)
J'ai lu plus haut :
> Selon mes calculs, vous devriez tenir au minimum de 2500 consultations simultanées sans problème, soit environ 10.000 à 12.000 utilisateurs loggués.
Donc vous avez déduit que, dans votre cas, Nb d'utilisateurs connectés * 4 = nb utilisateurs loggués ?
- à partir de combien d'utilisateurs simultanées (ou de quelles autres critères), pensez-vous qu'il soit nécessaire de faire du Load Balancing et donc d'utiliser un proxy ?
- quel temps de réponse de la page avez-vous déterminé comme acceptable ? (Valéry parle d'un temps de réponse d'1/2 seconde, était-ce la limite que vous aviez fixé?)
- comment (quels logiciels, procédures) avez-vous fait votre montée en charge ?
Notamment pour les "1450 utilisateurs simultanés exécutant des scénarios de navigation "connecté" dans les volumes de cours" ?
NB : j'ai vu que Valery parle ailleurs de "tests exhaustifs réalisés à partir du produit professionnel LoadRunner de Mercury Interactive.". Vous avez tout fait avec ?
Et les autres ?
- pouvez-vous nous dire comment vous avez réglé MYSQL :
> Nombre max de requêtes admises,
> Taille des buffers de threads,
> Mémoire allouée aux buffers de threads,
> Mémoire allouée aux tables d'indexes
- pensez-vous que notre configuration cible est suffisante ? Comment calculer le nombre d'utilisateurs simultanés et loggués que nous supporterons ?
*Observations et tests en cours*
D'après nos observations, nous n'avons pas de problème du tout avec le serveur MYSQL : les processeurs sont à peine sollicités (5-10% avec des pics à 40% la nuit lors des sauvegardes). Nous avons cependant augmenter le nombre de connexion simultanées (à "100" par défaut), trop juste lors des pics de fréquentation.
Le serveur web par contre est très sollicité : le processeur est très sollicité et les temps d'accès ne sont pas rapides même en temps "normal".
J'ai pu lire dans les forums :
Il faut savoir qu'un page Moodle consomme 90% de son temps en PHP contre moins de 10% dans MySQL.
mais j'ai aussi lu :
Chez nous, puisque MySQL et Moodle ne sont pas sur la même machine, il est facile de constater que le serveur Moodle se tourne les pouces alors que le serveur MySQL est saturé peu après qu'on a démarré l'application Moodle...
Nous avons commencé les tests de montée en charge avec "Siège" et nous surveillons l'état du serveur web avec Monit et Munin.
Je pensais aussi utiliser AB et LBS.
Cependant, sur quels critères faire ces tests ? Mis à part le temps de réponse et la saturation de la mémoire ? Les processeurs semblent toujours saturer dès lors qu'on commence les tests.
- Anne Remy :
Pouvez-vous m'indiquer combien d'utilisateurs simultanées/loggés/potentiels vous avez ? Combien vous pensez pouvoir en supporter avec votre architecture ?
Et combien de serveurs avez-vous mis en place ?
Vous dites que "La configuration du serveur a été adaptée (RAM et optimisation de la configuration Mysql notamment).", pouvez-vous donner des détails ?
- Anne Remy / Valery Fremaux / les autres (!)
Avez-vous lancé le script suivant que l'on peut trouver ici sur Moodle.org ?
Si oui, combien de Maximum concurrent users (approx), votre installation supporte-t-elle ?
Ma configuration cible obtient le résultat suivant que je trouve peu élevé (178 concurrent users) :
Ceci dit je ne sais pas du tout bien comment ce script calcule les chiffres donc je vais pas me baser dessus tant que je n'ai pas plus d'informations et de comparaisons fiables. Si qq'un l'a déjà lancé et peut m'en dire plus !
Je m'adresse en particulier à Valery et Anne qui se sont exprimés mais toute expérience est bienvenue.
Si certaines de mes questions sont trop spécifiques ou si vous ne souhaitez pas y répondre ici, je comprendrais !
Merci pour votre aide !
Pascal
De notre coté, nous avons mis en place Moodle en production cette année et nous avons rencontré des ralentissements juste avant les examens.
* Configuration actuelle *
- Serveur Web
MAC Xserve 2xG5/2.33 GHz
2 Go RAM
Disques SATA en RAID 1 logiciel
Apache2, PHP5, Moodle 1.9.8
- Serveur BD
MAC Xserve 2xXeon 2.0 GHz Dual Core Xeon 5130 (64 bits)
3 Go RAM
1 To SATA drives RAID 1
MYSQL 5
Les 2 serveurs ne servent pas que Moodle (autres sites, autres bases).
* Statistiques relevés *
Nombre total d'utilisateurs Moodle : 4500
Nombre d'enseignants Moodle : 100
Nous avons en moyenne 7/800 visites par jour (stats Piwik, "installé" uniquement sur la page d'accueil)
Au moment des ralentissements :
-> 1900 visites / jour (stats piwik)
-> 163 visites / heure (stats piwik)
-> ~70 visiteurs dans les 5 dernières minutes (logs moodle)
-> 16220 nb d'actions / jour (logs moodle : http://moodle.xx/course/report/log/index.php)
* Projection *
L'année prochaine, nous allons étendre Moodle aux 35000 utilisateurs potentiels.
Mais ces 35000 utilisateurs potentiels utilisent déjà les autres plate-formes que Moodle va remplacer, nous avons donc les statistiques de cette année. Nous nous attendons à avoir, au moins :
- en moyenne 1400 visites par jour ("visites" de la page d'accueil)
- 3300 visites / jour (stats piwik) en pointe
Bref les connexions devraient doubler mais nous nous attendons à une augmentation supplémentaire notamment avec l'élargissement du C2i.
* Configuration prochaine *
Nous pensons conserver notre serveur de base de données et, dès la fin du mois, nous allons changer le serveur web pour un serveur Supermicro :
2x INTEL XEON L5506 (Quad-core) 2.90 Ghz (~)
8Go DDR3 RAM
Seagate Barracuda 7200.11 SATA-300-7200trs/m-32 Mo (RAID 5 hard)
Avec Ubuntu 10.04, PHP5, Apache2, APC, Moodle 1.9.8
** Questions **
Nous sommes en phase de test de montée en charge. Je viens donc à la recherche d'informations sur le dimensionnement de configurations déjà en place relatives aux nombres d'utilisateurs. Et je viens aussi à la recherche d'informations sur la manière de pratiquer des tests de montée en charge.
J'ai bien conscience que les réponses sur ce sujet sont souvent difficiles à donner et dépendent beaucoup de l'environnement, cependant, j'ai qq questions précises suite à ce que j'ai lues, et qq questions générales.
Pour ceux qui ont déjà mis en place des serveurs en production (je pense notamment à Anne Remy ou à Valéry Fremaux qui se sont exprimés ici) :
- comment avez-vous estimé votre nombre d'utilisateurs simultanés ? par rapport à des stats observés ? au nombre d'utilisateurs potentiels ?
Pouvez-vous donner aujourd'hui le rapport nombre d'utilisateurs potentiels/loggués/simultanés ? (même si je comprends qu'ils dépendent de bcp de choses)
J'ai lu plus haut :
> Selon mes calculs, vous devriez tenir au minimum de 2500 consultations simultanées sans problème, soit environ 10.000 à 12.000 utilisateurs loggués.
Donc vous avez déduit que, dans votre cas, Nb d'utilisateurs connectés * 4 = nb utilisateurs loggués ?
- à partir de combien d'utilisateurs simultanées (ou de quelles autres critères), pensez-vous qu'il soit nécessaire de faire du Load Balancing et donc d'utiliser un proxy ?
- quel temps de réponse de la page avez-vous déterminé comme acceptable ? (Valéry parle d'un temps de réponse d'1/2 seconde, était-ce la limite que vous aviez fixé?)
- comment (quels logiciels, procédures) avez-vous fait votre montée en charge ?
Notamment pour les "1450 utilisateurs simultanés exécutant des scénarios de navigation "connecté" dans les volumes de cours" ?
NB : j'ai vu que Valery parle ailleurs de "tests exhaustifs réalisés à partir du produit professionnel LoadRunner de Mercury Interactive.". Vous avez tout fait avec ?
Et les autres ?
- pouvez-vous nous dire comment vous avez réglé MYSQL :
> Nombre max de requêtes admises,
> Taille des buffers de threads,
> Mémoire allouée aux buffers de threads,
> Mémoire allouée aux tables d'indexes
- pensez-vous que notre configuration cible est suffisante ? Comment calculer le nombre d'utilisateurs simultanés et loggués que nous supporterons ?
*Observations et tests en cours*
D'après nos observations, nous n'avons pas de problème du tout avec le serveur MYSQL : les processeurs sont à peine sollicités (5-10% avec des pics à 40% la nuit lors des sauvegardes). Nous avons cependant augmenter le nombre de connexion simultanées (à "100" par défaut), trop juste lors des pics de fréquentation.
Le serveur web par contre est très sollicité : le processeur est très sollicité et les temps d'accès ne sont pas rapides même en temps "normal".
J'ai pu lire dans les forums :
Il faut savoir qu'un page Moodle consomme 90% de son temps en PHP contre moins de 10% dans MySQL.
mais j'ai aussi lu :
Chez nous, puisque MySQL et Moodle ne sont pas sur la même machine, il est facile de constater que le serveur Moodle se tourne les pouces alors que le serveur MySQL est saturé peu après qu'on a démarré l'application Moodle...
Nous avons commencé les tests de montée en charge avec "Siège" et nous surveillons l'état du serveur web avec Monit et Munin.
Je pensais aussi utiliser AB et LBS.
Cependant, sur quels critères faire ces tests ? Mis à part le temps de réponse et la saturation de la mémoire ? Les processeurs semblent toujours saturer dès lors qu'on commence les tests.
- Anne Remy :
Pouvez-vous m'indiquer combien d'utilisateurs simultanées/loggés/potentiels vous avez ? Combien vous pensez pouvoir en supporter avec votre architecture ?
Et combien de serveurs avez-vous mis en place ?
Vous dites que "La configuration du serveur a été adaptée (RAM et optimisation de la configuration Mysql notamment).", pouvez-vous donner des détails ?
- Anne Remy / Valery Fremaux / les autres (!)
Avez-vous lancé le script suivant que l'on peut trouver ici sur Moodle.org ?
Si oui, combien de Maximum concurrent users (approx), votre installation supporte-t-elle ?
Ma configuration cible obtient le résultat suivant que je trouve peu élevé (178 concurrent users) :
| Processor performance | |||
| Function calls | 2160000 | 2201000 | |
| Regular expression replaces over 1KB of text | 17400 | 17400 | |
| Disk performance | |||
| 16KB files read from disk (cache) | 87700 | 88000 | |
| 16KB files written to disk (cache) | 600 | 800 | |
| Database performance | |||
| Get_record calls on the course table | 2000 | 2000 | |
| Insert_record calls on the course table | 1000 | 1000 | |
| Update_record calls on the course table | 230 | 150 | |
| Maximum concurrent users (approx): | 178 | ||
Ceci dit je ne sais pas du tout bien comment ce script calcule les chiffres donc je vais pas me baser dessus tant que je n'ai pas plus d'informations et de comparaisons fiables. Si qq'un l'a déjà lancé et peut m'en dire plus !
Je m'adresse en particulier à Valery et Anne qui se sont exprimés mais toute expérience est bienvenue.
Si certaines de mes questions sont trop spécifiques ou si vous ne souhaitez pas y répondre ici, je comprendrais !
Merci pour votre aide !
Pascal
Bonjour,
Je me réponds à moi-même 1 an après ... :D
Configuration actuelle
La configuration actuelle est celle décrite dans mon message précédent (1 serveur de BD MAC Xserve, 1 serveur web Supermicro). Nous avons d'autres sites internet et d'autres bases installés sur ces serveurs. Nous avons aussi une 2e plate-forme Moodle sur un autre serveur Supermicro identique.
Statistiques
Notre plate-forme compte aujourd'hui 544 cours et 13 000 utilisateurs. Mais 2500 ne sont se sont pas connectés depuis la rentrée et 4500 se sont connectés il y a plus de 3 mois. Donc on considère que 8500 utilisateurs sont réellement actifs.
Piwik
Mes projections étaient bonnes; Piwik nous permet de voir le nombre nombre de visiteurs, depuis le mois de septembre 2010 à ce jour :doublé
- moyenne de 42 180 visites par mois, pics :
> 62 750 en novembre 2010
> 54 163 en mars 2011
- moyenne de 1406 visites par jour, pics :
> 3080 visites en novembre 2010
> 2621 visites en janvier 2011
NB : Piwik est installé dans le "thème" donc fonctionne sur tout le site.
Logs Moodle
Au niveau des logs de moodle (table logs) :
- moyenne de 14 000 actions et 700 utilisateurs distincts par jour, pics :
-> 70 000 actions / jour et 1500 utilisateurs distincts en janvier 2011
- moyenne de 66 actions et 25 utilisateurs distincts par tranche de 5 minutes, pics : (1)
-> 2239 actions/5 minutes (par 61 utilisateurs distincts) en mars 2011
-> 227 visiteurs dans les 5 minutes (ayant effectué 648 actions dans la tranche des 5') en janvier 2011
Cependant, nous avons eu des pics plus de 5000 visites/jour l'année dernière (alors qu'il y avait beaucoup moins d'utilisateurs) lors de la période des examens de juin.
Ces pics avait généré des ralentissements malgré le changement de serveur. Le problème venait en fait de la configuration du serveur MYSQL.
Le processeur de ce dernier était à 60/80% au lieu de 20% en temps normal.
Nous avons fait les modifications suivantes au niveau de la configuration de MYSQL :
table_cache = 1024 / au lieu de 512
thread_concurrency = 16 /au lieu de 8
max_connections = 1500 / au lieu de 500
Depuis, nous n'avons plus observé de ralentissements et le processeur du serveur est à 20% d'activité en moyenne sans pics visibles (hors sauvegardes). Mais nous attendons de passer juin cette année pour analyser la charge à ce moment là.
(1) Ces statistiques ont été déterminé via le script que je joins en PJ. Il s'agit d'un script très basique, non optimisé, qui me sert de point de départ pour mes statistiques. Cependant, le temps que je regarde ce qui existe et que j'améliore ce script, il peut se passer du temps. Je fournis donc le script avec la mise en garde suivante : bien qu'il renvoie une page HTML, le script est finalement trop lourd pr être executer via le navigateur (en tout cas avec ma table de log de 3 500 000 de lignes). Je l'ai donc lancé en ligne de commande :
$ php -f outil_comptage_log.php > resultat.html
Pour info, le temps d'execution a été de 3.5 minutes de mon coté. De plus, je constate certains écarts entre le nombre de lignes que je trouve par jour avec la page http://moodle.xx/course/report/log/index.php (qui exploite la même table log) et ce que je trouve dans mon script (cependant la somme des actions est la même).
Ce script est donc fourni sans garantie !
Perspective.php
Je relance aujourd'hui ce script et j'obtiens le même résultat. Mais à part ce constat, je ne sais toujours pas comment interpreter ce script ni ces chiffres !
Processor performance
Function calls 3034000 3051000
Regular expression replaces over 1KB of text 18100 18100
Disk performance
16KB files read from disk (cache) 79700 80200
16KB files written to disk (cache) 700 800
Database performance
Get_record calls on the course table 1900 1900
Insert_record calls on the course table 670 700
Update_record calls on the course table 210 210
Maximum concurrent users (approx): 178
Projection
Moodle s'adresse à nos 35 000 utilisateurs potentiels. Cependant, à ce jour seul un tiers voir un quart l'utilise aujourd'hui. Avec le succès de l'automatisation de la création de cours pour les enseignants mise en place cette année, je pense que les chiffres vont doubler à la rentrée prochaine. Peut être que le nombre d'utilisateurs total ne dépassera pas les 20 000 utilisateurs mais les visites et l'activité générale devrait augmenter significativement.
Je table sur une moyenne de 2500 visites par jour et 3500 ou 4000 en pointe (voir 6000 en juin mais nous en saurons plus avec l'activité de "juin 2011").
Pour autant, il ne me semble pas nécessaire de changer de configuration. Nous mettons actuellement en place des outils pour connaitre précisément l'occupation de nos serveurs (CPU, RAM, disque, etc ...). Le serveur de base de données nécessitera peut être un upgrade.
Afin d'anticiper l'intensification de l'activité mais aussi pour réduire les risques d'interruption de service, nous envisageons à terme de migrer vers des systèmes virtualisés (déjà en place pour d'autres serveurs).
Connexions simultanées
Je ne peux pas dire aujourd'hui combien de connexions simultanées mon infrastructure peut supporter, tout d'abord car il faudrait définir cette notion et car je ne sais toujours pas comment la calculer réellement.
Les outils d'occupation de nos serveurs liés aux statistiques devraient nous éclairer, notamment avec le passage de juin.
Pascal