Performance

Faites que votre site fonctionne sans heurt et de manière aussi réactive que possible.

Est-ce que 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 nous arrêter et 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 mais 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 pour 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é de choses que n’importe quel script peut faire.

Si vous prenez au sérieux le sujet de la scalabilité, vous aurez probablement envie de considérer un certain nombre de choses vous-même.

Mesurez d’abord

Il ne sert à rien de dépenser 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 un outil de profilage afin de pouvoir identifier où votre goulot d’étranglement se situe, surtout si vous envisagez de dépenser de l’argent sur ce 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 astuces de configuration qui pourraient 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’il 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 requête 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 requête et de le passer aux requêtes suivantes, économisant ainsi à chaque requête tout le travail de calcul. Nous discutons ci-dessous 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 des 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 au lieu de la nouvelle version fournie par votre plugin.

Le cache simple 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 web vers le répertoire assetroot spécifié dans votre configuration (par défaut il est situé dans /path/to/dataroot/caches/views_simplecache/ :

cd /path/to/wwwroot/
ln -s /path/to/dataroot/caches/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 des 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

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 configurer la durée de validité de ce cache vous devez définir la valeur du TTL dans votre fichier settings.php : $CONFIG->boot_cache_ttl = 3600;

Cache des requêtes de base de données

Pour la durée de vie de l’exécution d’une page donnée, un cache de toutes les requêtes SELECT est conservé. Cela signifie que pour le chargement d’une page donnée, une requête sélectionnée donnée ne sortira dans la base de données qu’une seule fois, même si elle est exécutée plusieurs fois. Toute écriture dans la base de données videra ce cache. Ce cache sera automatiquement effacé à la fin du chargement d’une 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 actifs 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 quelles technologies sont utilisées actuellement sur votre serveur.

Si les actifs statiques ne sont pas mis en cache :
  • Vérifiez que vous avez ces extensions et qu’elles sont activées sur votre hébergement

  • Mettez à jour votre fichier .htaccess, si vous faites une mise à niveau depuis une version précédente de Elgg

  • Activez Simplecache, qui transforme les vues sélectionnées en actifs pouvant être mis en cache par le navigateur

Memcached

Libmemcached a été créé par Brian Aker et a été conçu dès le départ pour offrir la meilleure performance possible aux utilisateurs de Memcached.

Pré-requis pour l’installation :

  • php-memcached

  • libmemcached

  • memcached

Configuration :

Dé-commentez et renseignez les sections suivantes dans le fichier settings.php

$CONFIG->memcache = true;

$CONFIG->memcache_servers = array (
    array (
        'host' => 'server1',
        'port' => 11211
    ),
    array (
        'host' => 'server2',
        'port' => 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. Afin de faire cela, dé-commentez la ligne suivante

$CONFIG->memcache_namespace_prefix = '';

Squid

Nous avons obtenu de bons résultats en utilisant Squid pour mettre en cache les images.

Mise en cache du code exécutable - « bytecode »

Il existe de nombreux caches de code disponibles sur le marché. Ceux-ci accélèrent votre site en mettant en cache le 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 fonction PHP readfile().

Optimisation de l’Autoloader de Composer

Le chargeur automatique Composer est responsable du chargement des classes fournies par les dépendances de Elgg. La façon dont le chargeur automatique fonctionne est qu’il recherche un nom de classe dans les dépendances installées. Bien qu’il s’agisse principalement d’un processus rapide, il peut être optimisé.

Vous pouvez optimiser l’autoloader de 2 façons différentes. La première est via la ligne de commande, l’autre est d’utiliser le fichier composer.json de votre projet.

Si vous souhaitez optimiser le chargeur automatique à l’aide de la ligne de commande, utilisez le drapeau -o. L’inconvénient est que vous devez ajouter le drapeau -o à chaque fois que vous exécutez Composer.

# During the installation
composer install -o

# Or during the upgrade process
composer upgrade -o

La deuxième option consiste à ajouter l’optimisation à votre fichier composer.json, de cette façon vous ne l’oubliez jamais.

{
        "config": {
                "optimize-autoloader": true,
                "apcu-autoloader": true
        }
}

Voir aussi

Consultez la page d’optimisaiton de l’auto-chargement Autoloader Optimization pour plus d’informations sur l’optimisation du chargeur automatique Composer.

Note

À partir de Elgg 3.0 tous les téléchargements de Elgg à partir du site disposent du chargeur automatique optimisé.

Hébergement

N’espérez pas faire tourner un site avec 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.

Au sujet d’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 ayant un 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 de Elgg.

Il est très difficile de mettre en cache les sorties templates - des modèles de mise en page - dans la mesure où ils prennent généralement des entrées arbitraires. Au lieu d’essayer de 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 faire le travail 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 travail de développement supplémentaire significatif. L’équipe de Elgg envisage d’intégrer cette stratégie directement dans Elgg, dans la mesure où c’est aussi efficace, tout particulièrement pour les pages avec du contenu répété ou masqué.