Conseils de performance pour une large base d'utilisateurs
Je prépare un site avec de nombreux utilisateurs (plus de 100 000). Étant donné que la sortie dépend de la relation de l’utilisateur actuel avec certains types de publications et taxonomies personnalisés, un cache statique n’aidera pas grand-chose.
En plus d'utiliser une table séparée pour les utilisateurs et de servir des fichiers statiques à partir d'un domaine sans cookie, que puis-je faire pour améliorer les performances?
Par exemple: Dois-je utiliser InnoDB ou MyISAM? Des indices sur les index?
Mettre à jour
De toute évidence, je n’étais pas assez clair. Pardon.
Tous les utilisateurs sont connectés. Toujours. Personne d'autre ne peut en voir plus que la page de démarrage. Le site propose du matériel payant pour les cours en ligne.
Je recherche des conseils relatifs à une base d'utilisateurs importante uniquement. Les optimisations de base des performances générales telles que la compression, le chargement paresseux de scripts, les images-objets, etc. sont utiles, mais ce n’est pas ce que je recherche.
Vous pouvez utiliser "W3 Total Cache" , qui n'est pas un système de cache de fichiers statique. Toutefois, il utilise des éléments tels que la mise en cache des opcode, la mémorisation en cache et la mise en cache des objets pour réduire le temps de chargement des pages. APC, ou un autre opcache, serait un bon ajout à votre serveur, de même qu’utiliser un httpd léger au lieu d’Apache gonflé.
Forcer GZIP sur les utilisateurs est également considéré comme une bonne idée car la plupart des personnes qui ne reçoivent pas de fichiers GZIP sont en mesure de recevoir des fichiers GZIP. Les en-têtes de requête peuvent être gérés par des pare-feu, etc.
Cependant, 80% du chargement des pages se fait généralement au début de l’année, c’est donc un endroit sur lequel vous voudrez travailler. "W3 Total Cache" fait la concaténation de CSS et JavaScript ainsi que la minification des fichiers. C’est la meilleure option si vous avez correctement récupéré vos fichiers JavaScript et CSS afin de les afficher uniquement sur les pages où ils sont nécessaires. Cependant, la plupart des sites ne le font pas, sa configuration supplémentaire requise n’est donc que gênante. De plus, la minification des fichiers aboutit généralement à la casse, aussi je fais la concaténation des fichiers.
L'utilisation de la fourniture de fichiers statiques à un domaine sans cookie économisera quelques ms, mais pour réaliser de réelles économies de chargement de pages, l'utilisation d'un CDN économisera environ 100 ms par élément. L'utilisation de plusieurs domaines pour servir les fichiers augmentera également la charge de page pour les navigateurs plus anciens qui ont des limites quant au nombre de demandes de fichiers simultanées pouvant être effectuées par domaine.
Vous pouvez également envisager d'utiliser http://smush.it pour économiser la taille des images sans perte de qualité. ( https://github.com/icambridge/filesmush script pour l'exécution de fichiers locaux via smushit. https://github.com/tylerhall/Autosmush pour exécuter des images sur S3 via smushit.)
InnoDB doit être utilisé si vos commentaires sont nettement plus nombreux que vos messages. Sinon, MyISAM pourrait être plus rapide.
Peut-être pouvez-vous passer à mySQL 5.5 avec le standard innodb par défaut. En outre, l'utilisation d'un équilibreur de charge et la séparation des tables utilisateur dans une autre base de données, un serveur supplémentaire, constituent un changement.
D'accord avec ce que @Backie a écrit.
wp-supercache dispose également d'un support expérimental pour la mise en cache d'objets utilisant APC et le support CDN. J'ai trouvé que la mise en cache des objets peut entraîner un comportement étrange de plugins écrits (mal?).
MyISAM sera généralement plus rapide, sauf si vous avez beaucoup d'écritures (principalement des commentaires), car il ne verrouille qu'une page, pas tout le tableau.
Assurez-vous d'activer la journalisation lente des requêtes MySQL et vérifiez où se trouvent vos réels goulets d'étranglement, puis utilisez EXPLAIN pour déterminer si vous devez ajouter des index, etc. Cette page est une très bonne introduction si vous n’avez pas utilisé EXPLAIN auparavant.
Le script mysqltuner peut également être utile pour déterminer où vous pourriez avoir besoin d'ajuster votre configuration MySQL.