Valery Fremaux

En effet, je suis en train de soumettre toute la procédure de login à une analyse de microbench pour savoir où Moodle passe le temps.

J'ai déjà identifié que la constitution du cache de capacités lors d'un login initial d'un utilisateur est semble-t-il un endroit à problème. Chez moi, il arrive même que la fonction de revienne jamais et c'est "page blanche" dans le navigateur, alors que le login est effectif.

Tombez-vous sur ce genre de cas ? 

Apparemment, si ce cache est constitué, le login du même utilisateur (même à partir d'une session de navigateur complètement différente) est plus rapide, mais ce cache n'a pas une très grande durée de vie.

Je dois fouiller plus en détail le code de lib/accesslib.php pour comprendre ce qui se passe dans la fonction

load_user_capability($capability='', $context=NULL, $userid=NULL, $checkenrolments=true)

PS: il n'empeche qu'un accélérateur apporte quand même un gain notable. 

Bon, après mon déversage de fiel précédent, un début de solution qui marche pas mal :

mettre php sous eAccelerator : gain de temps entre 230 et 300 %

Le principe, mettre en cache mémoire les scripts PHP préparsés.

http://www.eaccelerator.net

Si la machine est dédiée au Moodle, ça bouffe de la mémoire de cache, mais sa factorise pas mal.

Je tourne avec beaucoup moins d'étudiants (800 comptes, 10 à 15 simultanés) sur un vieux Pentium II 450 MHz avec 384 Mo de RAM + un encore plus vieux 350 Mhz avec 256 Mo de RAM pour MySQL5 (!!).

Mêmes temps de réponses pour le premier login (environ 15 secondes, accroché à un LDAP de l'école). Je suis derrière un proxy/reverseproxy (un autre apache qui tourne en php4). temps de réponse unitaire des pages (page de plan de cours chargé : entre 2 et 5 secondes, formulaires d'activité : entre 1.5 et 2.5 secondes).

Tout à fait exact.

OVH dispose également d'un offre pas très visible qui s'appelle SQLplan et qui te permettrait de ne pas jongler avec toutes ces bases.

Le souci, c'est que jusqu'à il y a quelques temps, ces SQL plan ne tournaient pas en MySQL 5. Mais le prix est correct et permet d'avoir des grosses bases.

Le font-il toujours ?

A noter qu'une base Moodle pour environ 1000 utilisateurs doit prendre aux environs de 80 à 100 Mo une fois chargée de logs et de ressources... 

A tous :

Le code du moteur de recherche "total" a été entièrement mis à jour sur le CVS. Vous pouvez le récupérer en updatant :

/search
/blocks/search

puis en récupérant deux librairies extractrices de texte dans

/contrib/patches/global_search_libraries

a déployer dans /lib, livrées en version Linux et win32.

la configuration du bloc search est nécessaire (au moins une fois) avant d'utiliser le moteur, pour fixer certains paramètres importants (dont les bindings des utilitaires d'extraction de texte pour PDF et MSWord). 

Il faut également copier les fichiers de langue de l'extension noyan /search (qui ne sont pas pris en charge comme les blocs et les modules).

Pour pouvoir rechercher, il faut installer un bloc de recherche et il faut lancer une première indexation du contenu*. Attention, cela peut être TRES LONG si la plate-forme est pleine de documents, de ressources, de messages ou de fiches de glossaires ou de données. 

(*) on accede à l'indexation par une recherche "blanche" sous admin, puis en suivant le lien "statistiques" puis indexersplash.php

Le rapport d'indexation n'est pas traduit (en anglais) et sort en "text brut".

Cas d'indexation incomplete (avortée) : si l'indexation est trop lourde et finit par planter le processus, on peut lancer à la main la page %WWWMOODLE%/admin/cron.php pour aider à compléter l'index. La maintenance de l'index est incrémentale, et si elle se plante elle-aussi, on peut la relancer jusqu'à avoir terminé l'indexation complète.

(bon ça c'est de la théorie, mais je vais essayer le plus tôt possible sur http://www.ethnoinformatique.fr pour voir.).

Bonne nuit à tous.

Martin, you told me about Events for making cross-modules API. I read it out and wonder what is the processing path for 'instant' events.

My goal is making one module (some project dedicated module) ask for data to a potentially not installed module, and to bind such instance of a coursemodule to exacly such other instance, as they are fit to work (potentially) together. Another situation could be plugin a module within another so that part of its data model get shared with part of another. Say, when adding a task module (Jeff Graham's), I can bind that module to use a techproject task outline rather than its internal model, or even just some of the attributes.

As Events are essentially an asynchronous triggering method (seems trivial when croned, that cron framework will consume all queued events), I fear such very synchronous form of cooperation does not exactly fit, as this is not a straight implementation of the Observer pattern in that way I wonder how the triggered event can give data back to another module for displaying in its caller screen.

So my main question : when triggering out an "instant' event, what is the path ? How could I lock and wait for a synchronous answer (supposed it is an answering event) of the triggered module ? (e.g. in order to complete my output with the data I get from that anwser).

In case events are not exactly suited for this kind of cooperation, how to get a real synchronous Listener registration pattern ?