Valery Fremaux

Vos "galères" de répartition m'intéressent... j'ai dû pour ma part modifier pas mal le réglage de dimensionnement des clusters récemment pour ne pas bloquer le système (limite de création d'indexes, de tables, etc). Les performances sont encore en effet un peu "douteuses", mais comme nous sommes sur des VMWares avec très peu de mémoire et des conditions de réseau peu connues, difficile de se faire une idée.

Je vais voir si on peut faire des tests pour confirmer ces différences...

Nous travaillons avec l'équipe de Catalyst actuellement et avons demandé une assistance experte sur la réplication de Postgress. Postgress semble beaucoup plus stable et plus optimisée en général.

Une question est : comment pouvez vous mesurer qu'il s'agit d'une charge MySQL et non une charge PHP ? (Ca m'intéresse !!)

Nous prévoyons (et sommes en train de tester) pour le projet Pairformance (Intel/MEN) qui vise 100.000 utilisateurs et 2500 connectés simultanés une mise en cluster sous HAProxy avec trois frontaux Web et un double MySQL clusterisé en NDBCLUSTER.

Nous n'avons aujourd"hui fait que valider le fonctionnement du dispositif et pas encore l'hypothèse de montée en charge.

Si la charge MySQL pure peut être mise hors de cause, une première solution assez économique reste cette clusterisation de frontal. Nous avons placé les volumes contenant le code Moodle sur un volume partagé NFS (pas la meilleure solution, mais c'est pour éviter les synchros de la base de code). La perte de performance par rapport à des copies locales de la racine Moodle ont été mesurées comme perceptibles (essais subjectifs, demande à être approfondi). Avec une répartition sur deux machines, ça tourne correctement d'un point de vue 'architecture'. HAProxy est assez rapide à mettre en oeuvre, et il peut lui même être redondé. Il faut simplement que le système soit "symétrique" ce qui suppose que le Load Balancer soit sur une petite machine dédiée. Nous n'avons pas encore de mesure sur l'impact de la puissance du proxy sur l'ensemble du système.

Thanks Martin for those wise considerations. I was guessing distributed search had some effective and important drawbacks on performance and cross-load effects between nodes.

Asynchronously fetching remote indexes may be a reachable goal. I will study that way of doing right now, and try to know more about Lucene to make that broadcast possible.

I will update this thread with results of my investigations.

Cheers.  

Hi fellows,

I'm starting implementation of the Mnet enabled Global Search. Here are some ideas I'm upon to put in :

- The mnet harvesting will be separately disabled using an additional block_search configuration switch.

- In order to protect remote hosts against massive load attacks comming from heavy search activity, an additional configuration parameter should limit the amount of records that will be fetched through the network call.

Mnet search will add a new mnet service so called "mnet_search".

Publishing that service will allow to accept remote query calls and give back a hitset.

Suscribing to this service allows launching queries through the network.

The first version of the mnet search capability will be using synchronous calls, from the local querier, which is not that performant. I am thinking about using parallel Ajax queries to get remote results and aggregate results client side. Asynchronous calls will anyway use a local wrapper that must suscribe to the mnet_search service. This will be the next step. A new config switch will allow to choose how this harvesting is processed.

As most probable, synchronous calls will aggregate hits to the local hitset before results caching, thus navigating using the search cache WILL NOT throw network calls again.

OPEN QUESTION : Should aggregated results better be presented "by host", or should results be ordered by relevance ?

More news as development runs ahead.

Cheers.

Bonjour à tous,

je fais suite à une réunion tardive nocturne au dernier MoodleMoot sur le problème des devoirs de groupe...

Nous avons eu chez nous trois jours de séminaire technique avec Catalyst (un des plus gros Moodle Partner après Moodle Rooms) et notamment l'adorable et petillante Penny Leach. J'ai profité de la visite de cette éminente ancienne membre des HQ (HeadQuarters) pour discuter fermement du problème récurrent des devoirs collectifs, et de l'absence de solution dans la distribution officielle de Moodle. (pas vraiment dans les plans de 2.0, à ma connaissance).

L'une des solutions que nous avons évoqué serait la refonte (une deuxième, la dernière datait de 2 ans) du module "assignment" en montant une nouvelle abstraction (la première est cette du "type" de devoir) qui permettrait de séparer le mode (User ou Group, voire en prenant en compte les Groupements). Puis une proposition aux HQ d'une nouvelle version non "destructive" du comportement actuel. Ceci peut être obtenu par un réarchitecturage du code du module et des librairies. L'appui de Penny pour soutenir l'initiative, ainsi que d'autres appuis que nous pourrions avoir dans les différentes communautés nous aideront probablement, à la fois à trouver le temps nécessaire, mais aussi à promouvoir l'adoption de cette solution.

Penny n'était pas franchement favorable à la construction d'un clone de "assignment" (par exemple groupassignment) qui aurait en effet repris un grand nombre de structures du code précédent (ce qui constitue cependant la voie la plus rapide et facile).

Si quelqu'un a des infos plus fraîches sur la question... welcome. 

Moodlement vôtre.