Performance¶
Faites que votre site fonctionne sans heurt et de manière aussi réactive que possible.
Est-ce Elgg peut passer à l’échelle de X millions d’utilisateurs ?¶
Les gens demandent souvent si Elgg convient pour de grands sites.
Tout d’abord, nous pourrions vous arrêter pour demander: « où et comment prévoyez-vous d’obtenir tous ces utilisateurs? » Sérieusement, c’est un problème très intéressant. Faire évoluer Elgg est avant tout une question d’ingénierie technique. C’est intéressant, et plus ou moins un problème résolu. L’informatique ne fonctionne pas différemment pour Elgg que pour Google, par exemple. Obtenir des millions d’utilisateurs? C’est comme le Saint Graal de toute l’industrie de la technologie.
Deuxièmement, comme avec la plupart des choses dans la vie, la réponse est «ça dépend»:
Que font vos utilisateurs?
Sur quelle machine et avec quelle configuration fonctionne Elgg?
Est-ce que vos plugins se comportent bien?
Améliorer l’efficacité du moteur Elgg est un projet en cours, bien qu’il y ait des limites à la quantité que n’importe quel script peut faire.
Si vous êtes sérieux au sujet de l’évolutivité, vous aurez probablement envie de considérer un certain nombre de choses vous-même.
Mesurez d’abord¶
Il ne sert à rien de jeter des ressources sur un problème si vous ne connaissez pas:
quel est le problème
de quelles ressources ce problème a besoin
où ces ressources sont nécessaires
Investissez dans une sorte de profilage afin de vous faire connaître où votre goulot d’étranglement se situe, surtout si vous envisagez d’injecter de l’argent important sur un problème.
Régler MySQL¶
Elgg fait un usage intensif de la base de données en back-end, faisant, à chaque chargement de page, de nombreux appels et allers et retours entre le serveur web et la base de données. Ceci est parfaitement normal et un serveur de base de données bien configuré sera capable de faire face à des milliers de requêtes par seconde.
Voici quelques conseils de configuration qui pourraient bien vous aider :
Assurez-vous que MySQL utilise un fichier de configuration my.cnf adapté à la taille de votre site web.
Augmentez la quantité de mémoire disponible pour PHP et de même pour MySQL (vous aurez dans tous les cas à augmenter la quantité de mémoire disponible pour le processus de php)
Activer la mise en cache¶
En règle générale, si un programme est lent, c’est parce qu’elle effectue à plusieurs reprises un calcul ou une opération coûteuse. La mise en cache permet au système d’éviter de faire ce travail encore et encore à chaque demande grâce à la mise en cache des résultats précédents. En utilisant la mémoire pour stocker les résultats, il est alors facile de récupérer en mémoire le résultat de la demande et le passer aux demandes suivantes, économisant ainsi à chaque demande tout le travail de calcul. Ci-dessous, nous discutons de plusieurs solutions de mise en cache généralement disponibles et pertinentes pour Elgg.
Cache simple (Simplecache)¶
Par défaut, les vues sont mises en cache dans le répertoire de données de Elgg pour une période de temps donnée. Cela supprime la nécessité de régénérer chaque vue à chaque chargement de la page.
Ceci peut être désactivé en définissant $CONFIG->simplecache_enabled = false; Pour de meilleures performances, assurez-vous que cette valeur est bien définie sur true.
Cela conduit à des artefacts pendant le développement/la programmation si par exemple vous modifiez un thème dans votre plugin puisque la version mise en cache sera utilisée de préférence à la nouvelle fournie par votre plugin.
Simple cache peut être désactivée via le menu d’administration. Il est recommandé de le faire sur votre plate-forme de développement si vous écrivez des plugins Elgg.
Ce cache est automatiquement vidé à chaque fois qu’un plugin est activé, désactivé ou réorganisé, ou quand le script upgrade.php est exécuté.
Pour de meilleures performances, vous pouvez également créer un lien symbolique depuis /cache/ dans votre répertoire racine vers le répertoire /views_simplecache/ de votre répertoire de données que vous avez configuré lors de l’installation d’Elgg :
cd /path/to/wwwroot/
ln -s /path/to/dataroot/views_simplecache/ cache
Si votre serveur web supporte les liens symboliques (« symlinks »), ceci va servir les fichiers directement depuis le disque sans démarrer PHP à chaque fois.
Pour des raisons de sécurité, quelques serveurs web (par ex. Apache dans la version 2.4) pourraient par défaut ne suivre les liens symboliques que si le propriétaire de la source et de la cible du lien correspondent. Si le lien symbolique du cache ne fonctionne pas sur votre serveur web, vous pouvez changer le propriétaire du lien symbolique du cache lui-même (et non du répertoire /views_simplecache/) avec
cd /path/to/wwwroot/
chown -h wwwrun:www cache
Dans cet exemple on prend l’hypothèse que le répertoire /views_simplecache/ du répertoire de données appartient au compte wwwrun qui fait partie du groupe www. Si ce n’est pas le cas sur votre serveur, vous devez modifier la commande chown en conséquence.
Cache système (System cache)¶
L’emplacement des vues est mis en cache afin de retrouver rapidement les vues (en effet, le profilage a indiqué que le temps de chargement d’une page prend une quantité non-linéaire du temps plus il y a de plugins activés, ceci en raison de la recherche des vues). Elgg met également en cache des informations telles que la cartographie de la langue et de la carte des classes.
Ceci peut être désactivé en définissant $CONFIG->system_cache_enabled = false; Pour de meilleures performances, assurez-vous que cette valeur est bien définie sur true.
Les emplacements des vues sont actuellement stockés dans des fichiers placés dans votre dossier de données (toutefois des versions ultérieures de Elgg peuvent utiliser memcache). Comme avec le cache simple, le cache système est automatiquement vidé chaque fois qu’un plugin est activé, désactivé ou réorganisé, ou quand le script upgrade.php est exécuté.
Le cache du système peut être désactivé via le menu d’administration, et il est recommandé de le faire sur votre plate-forme de développement si vous écrivez des plugins Elgg.
Cache de démarrage (expérimental)¶
Elgg a la capacité de mettre en cache de nombreuses ressources créées et récupérées pendant le processus de démarrage. Pour activer ce cache, vous devez définir la valeur du TTL dans votre fichier settings.php : $CONFIG->boot_cache_ttl = 10;
Un TTL faible est recommandé parce que cela apporte tous les avantages de la mise en cache pendant la charge, tout en limitant les dégâts si la stratégie d’invalidation du cache de Elgg devait manquer quelque chose.
Cache des requêtes de base de données¶
Pour toute la durée d’exécution d’une page donnée, un cache de toutes les requêtes SELECT est conservé. Ceci signifie que pour le chargement d’une page donnée une requête select donnée sera envoyée à la base de données une seule et unique fois, même si elle est exécutée à plusieurs reprises. Toute écriture sur la base de données va vider ce cache, aussi il est conseillé que sur des pages complexes vous différiez les écriture sur la base de données après la fin de la page, ou utilisiez la fonctionnalité execute_delayed_*. Ce cache sera automatiquement effacé à la fin du chargement de la page.
Vous pouvez rencontrer des problèmes de mémoire si vous utilisez le framework Elgg comme bibliothèque dans un script PHP CLI. Ceci peut être désactivé en définissant $CONFIG->db_disable_query_cache = true;
Etags et headers Expires¶
Ces technologies indiquent aux navigateurs de vos utilisateurs de mettre en cache des ressources statiques (CSS, JS, images) localement. Avoir ceci activé réduit fortement la charge du serveur et améliore la performance perçue par les utilisateurs.
Utilisez le plugin Firefox yslow ou les Outils de Développement de Chrome DevTools Audits pour confirmer les technologies utilisées actuellement sur votre serveur.
- Si les ressources statiques ne sont pas mises en cache :
Vérifiez que vous avez ces extensions et activées sur votre hébergement
Mettez à jour votre fichier .htaccess, si vous faites une mise à niveau depuis une version précédente d’Elgg
Activez Simplecache, qui transforme les vues sélectionnées en ressources (assets) pouvant être mis en cache par le navigateur
Memcache¶
Memcache est une technologie de cache générique développée par Brad Fitzpatrick pour LiveJournal.
Avertissement
LE SUPPORT DE MEMCACHE EST EXPÉRIMENTAL ET PEUT ÊTRE CHANGE.
Pré-requis pour l’installation :
php5-memcache
memcached
Configuration :
Dé-commentez et renseignez les sections suivantes dans le fichier settings.php
$CONFIG->memcache = true;
$CONFIG->memcache_servers = array (
array('server1', 11211),
array('server2', 11211)
);
De manière optionnelle, si vous avez plusieurs installations Elgg mais n’utilisez qu’un seul serveur Memcache, vous pouvez vouloir ajouter un préfixe d’espace de nom (namespace prefix). Afin de faire cela, décommentez la ligne suivante
$CONFIG->memcache_namespace_prefix = '';
Mise en cache du Bytecode¶
Il existe de nombreux caches de code disponibles sur le marché. Ceux-ci accélèrent votre site en mettant en cache le byte code compilé depuis votre script, ce qui signifie que votre serveur n’a pas à compiler le code PHP à chaque fois qu’il est exécuté.
Servir directement les fichiers¶
Si votre serveur peut être configuré pour supporter les headers X-Sendfile ou X-Accel, vous pouvez configurer leur utilisation dans settings.php. Ceci permet à votre serveur web de diffuser directement les fichiers au client au lieu d’utiliser la focntion PHP readfile().
Hébergement¶
N’espérez pas faire tourner un site pour des millions d’utilisateurs sur un hébergement mutualisé à bas prix. Vous aurez besoin de votre propre serveur d’hébergement et d’avoir la main sur la configuration, ainsi que de beaucoup de bande passante et de mémoire disponibles.
Mémoire, CPU et bande passante¶
De par la nature de la mise en cache, toutes les solutions de mise en cache auront besoin de mémoire. C’est un investissement plutôt économique d’augmenter la mémoire et le CPU.
Sur un matériel puissant il est probable que la bande passante soit le goulet d’étranglement (bottleneck) avant le serveur lui-même. Assurez-vous que votre hébergement peut supporter le trafic que vous attendez.
Configuration¶
Enfin, jetez un coup d’œil à votre configuration car il y a quelques points d’attention qui peuvent surprendre les gens.
Par exemple, Apache peut d’emblée gérer une charge plutôt élevée. Cependant, la majorité des distributions Linux sont livrées avec mysql configuré pour de petits sites. Ceci peut peut donner lieu à des processus Apache bloqués qui attendent de pouvoir parler à un processus MySQL très surchargé.
Vérifiez les plugins au mauvais comportement¶
Des plugins peuvent être développés d’une manière très naïve et ceci peut ralentir l’ensemble du site.
Essayez de désactiver quelques plugins pour voir si cela améliore notablement les performances. Une fois que vous avez trouvé un responsable potentiel, rendez-vous sur la page de l’auteur du plugin et signalez vos résultats.
Utilisez du HTML rendu côté client¶
Nous avons constaté qu’à un certain niveau, une bonne partie du temps passé sur le serveur est simplement le temps de construction du HTML de la page avec le système de vues d’Elgg.
Il est très difficile de mettre en cache les sorties des modèles (templates) dans la mesure où elles prennent généralement des entrées arbitraires. Au lieu d’essayer mettre en cache la sortie de certaines pages ou vues, la suggestion est de basculer vers un système de modèles basé sur HTML de sorte que le navigateur de l’utilisateur puisse lui-même mettre en cache les modèles. Puis demandez à l’ordinateur de l’utilisateur de générer le résultat en appliquant des données JSON à ces modèles.
Ceci peut être très efficace, mais présente l’inconvénient de demander un coup de développement supplémentaire significatif. L’équipe d’Elgg envisage d’intégrer cette stratégie directemetn dans Elgg, dans la mesure où ceci est aussi efficace, tout particulièrement avec les pages avec du contenu répété ou caché.