Bonjour à tous,
Que ce soit sur des versions antérieurs ou actuelles d’Opale ou Chamilo, le monde des utilisateurs d’Opale et Chamilo semble se diviser en 2 catégories :
- ceux dont les pages scorm d’Opale (multi ou mono sco) se chargent rapidement ;
- ceux dont ça rame (6 à 12 secondes).
à priori comme on trouve des utilisateurs des 2 côtés (rame, rame pas) on pourrait présumer que c’est lié à la configuration du serveur.
J’ai posté un message à ce sujet sur https://chamilo.org/forum/viewtopic.php?f=14&t=5083#p29022 j’essaierai de centraliser les réponses là-bas, si vous êtes utilisateurs d’Opale et Chamilo, si vous pouvez, merci de faire part de votre retour (rame / rame pas) sur le lien du forum chamilo ou ici (dans ce cas je posterai votre réponse sur le forum de chamilo si ça ne vous dérange pas) et d’indiquer votre php.ini qui est pour le moment le premier suspect…
Merci 
Ghislain
1 « J'aime »
Bonjour Ghislain,
Il y a 3 choses à prendre en compte :
- A l’exception de ton dernier message, les autres infos datent de 2011 à 2014, parfois en utilisant encore les anciennes publi (clarolines) plutôt que la publi Scorm.
- La puissance du serveur peut avoir une influence sur la perception de la vitesse, entre un hébergement mutualisé et une plateforme dédiée sur un serveur 8+ core de moins de 2 ans il peut y avoir un facteur 10 (même si le SCORM est beaucoup plus lent que les autres pages sans complètement corriger le problème). Donc je recommande quand même d’indiquer le CPU, la ram, si d’autres activités tournent en même temps sur le serveur, si le serveur de base de donnée est sur la même machine ou pas…
- Le SCORM implique beaucoup d’appels à des fonctions ajax, et en plus de cela, la plateforme en rajoute souvent une couche au niveau sécurité : par exemple, pour accepter le fait que la plateforme puisse avoir certains modules privés, il faut que chaque fichier (chaque image ou autre ressource) passe dans tous le code php qui gère le controle d’accès de la plateforme. Par exemple si une page SCORM contient 10 images, 5 fichiers CSS, 5 fichiers javascript, le serveur va contrôler 20 fois que l’utilisateur de la LMS a accès à 20 fichiers différents et tout ce que cela implique (lecture des fichiers ou tables de configs, vérification que l’utilisateur est authentifié, vérification de l’accès lui même).
- Les pages qui passent par un contrôle d’accès ne sont pas toujours mises en cache car la plateforme peut considérer que l’utilisateur pourrait « perdre les droits » d’accéder à un cours. (cela peut quand même être une piste à explorer, car si tu as les moyens de les mettre en cache pour une durée d’une heure les fichiers JS/CSS/images de scenari, cela aide déjà bcp). C’est dans la config du serveur web, mais les développeurs web peuvent surcharger cette config, je ne sais pas si c’est le cas de chamilos.
- cela aide beaucoup de regarder l’onglet « network » des outils de dev. web firefox. (F12)
- la version 5.5+ de php propose opcache, si le problème est lié à la puissance brute du CPU cela permet un gain important (mais pas si le pb est lié à la base de donnée ou à d’autres mauvaises configuration).
- la version 7 de php est (d’après l’éditeur) beaucoup plus rapide que l’ancienne
Bonjour Stéphane,
Merci beaucoup pour toutes ces pistes, je vais décortiquer et tester tout ça…
Hello,
Petit retour d’expérience…
Sur un serveur mutualisé, en php 5.5, avec Opale 3.5 en multi-sco, sur Chamilo 1.10.2, avec le php.ini indiqué via le message précédent sur le forum chamilo, j’étais à 13 secondes environ par page.
Je n’ai pu tester l’utilisation de php 7 (sinon il fallait tout migrer et vérifier…), et n’ai pas les infos sur la RAM, CPU, et la localisation de la BDD, mais en agissant sur le contrôle de la plateforme des fichiers, le résultat est significatif : on se retrouve à 3-4 secondes par page. Après cela peut présenter des soucis si le contenu est privé, mais du moins, en copiant collant l’url de consultation scorm sur un autre navigateur sur lequel on n’est pas identifié, le contenu ne s’affiche pas.
Comme indiqué dans la doc d’optimisation de chamilo (votre url//documentation/optimization.html#11.permissions-check ), il faut supprimer dans le htaccess les infos suivantes : RewriteRule ([^/]+)/scorm/(.*)$ /main/document/download_scorm.php?doc_url=/$2&cDir=$1 [QSA,L]
Une méthode moins radicale est aussi proposée (supprimer le contrôle uniquement sur certains fichiers (css, polices, images…) mais je ne l’ai pas testé pour le moment.
voilà voilà…
Bonjour Ghislain et désolé pour l’énorme délai de réponse (on s’est parlé par e-mail bien avant, mais pour que ce post ne reste pas éternellement sans réponse, et étant donné que nous publierons très bientôt la version 1.11.6 de Chamilo, je tenais à faire le point. Pour d’autres qui liraient ce post sans me connaître, je suis le leader du projet Chamilo et il est donc important pour moi que des observations (légitime) de ce genre ne restent pas ignorées.
Le problème que tu mentionnes nous a été rapporté par de nombreux utilisateurs. Le seul point commun que nous avons trouvé était qu’ils utilisaient plus ou moins tous des infrastructures assez légères, et ils repéraient donc ce problème bien plus fortement que des utilisateurs en hébergement plus conséquent.
Chamilo étant très attentif à l’utilisation des ressources (l’un de nos arguments étant que Chamilo utilise environ 40% moins de processeur et de mémoire que Moodle dans un contexte d’utilisation de base), il est bien entendu important pour nous d’essayer d’y remédier (même si le parcours n’est pas le plus utilisé par des écoles déconnectées du tiers monde fonctionnant sur les laptops OLPC ou sur Raspberry Pi).
Je suis donc content de pouvoir affirmer qu’une première solution a été trouvée suite à la découverte d’une « erreur » dans la migration des versions 1.9 vers 1.10, ou plutôt dans le changement de structure de la base de données entre ces versions, puisque cela affecte également les nouvelles installations de 1.10 et 1.11.
Détail non nécessaire dans le paragraphe ci-dessous, passer pour ceux qui veulent seulement la solution:
Dans ces versions, nous avons modifié la structure de la base de données ajoutant un champ « iid » (clef primaire) dans toutes les tables de cours, puisque nous sommes passés (entre 1.8 et 1.9) d’une structure de multiples bases de données vers une structure de base de données unique (longue histoire que je ne détaillerai pas ici). Comme il est de coutume dans les bases de données relationnelles, nous avons donc utilisé cette nouvelle clef primaire comme index, modifiant le code de Chamilo pour utiliser des requêtes JOIN utilisant ce champ plutôt qu’une combinaison de deux champs différents (c_id et id) que nous utilisions auparavant. Malheureusement, dans ce processus, quelques requêtes nous ont échappé. C’est le cas d’une requête importante pour les parcours d’apprentissage dans Chamilo. Cela signifie en particulier que des requêtes sur les tables c_lp_item et consort chargées (avec plusieurs centaines d’enregistrements) seront particulièrement lentes, et de plus en plus lentes avec une quantité croissante d’enregistrements.
La solution donc, qui devrait accélérer considérablement le code d’une 1.10, serait de rajouter un index sur le champ « id » de la table c_lp_item. Ce n’est peut-être pas suffisant pour réduire le temps de chargement de 11s à 0.1s comme ça devrait être le cas, mais ça devrait sans trop de problème générer un boost de 10 fois la vitesse, si la table est particulièrement chargée.
Voilà, en espérant que ça t’aide encore. En tout cas, dans la version 1.11.6, le problème est corrigé dans le code et donc une mise à jour de 1.10 ou 1.11 vers 1.11.6 devrait apporter une accélération considérable du temps de chargement des pages de parcours.
1 « J'aime »
Excellent, merci Yannick pour ces infos détaillées, et pour les améliorations que vous avez apportées.