WordPress Performance MySQL
J'ai un site Web (www.americanbankingnews.com) qui reçoit 40 000 à 50 000 pages vues aujourd'hui. Il est actuellement installé sur un serveur Xeon quadricœur dédié avec 8 Go de RAM. Le site est propulsé par WordPress et MySQL (assis sur le même serveur) et j'utilise actuellement W3 Total Cache pour le cache de pages et de requêtes MySQL.
Malheureusement, cela ne semble pas être suffisant. Pendant les heures de pointe, mes serveurs reçoivent quelques erreurs HTTP 500 et les pages non mises en cache se chargent lentement.
Je n'utilise actuellement pas Xcache ni aucun autre outil de cache/accélération PHP.
Existe-t-il d'autres étapes à suivre pour optimiser les performances de MySQL et de PHP? Ou devrais-je utiliser un serveur supplémentaire? Plus précisément, j'aimerais avoir des suggestions supplémentaires pour améliorer les performances de MySQL et savoir si des outils tels que xcache pourraient aider dans cette situation.
Avant de vous intéresser à la machine, avez-vous effectué un audit approfondi des plugins, modèles, etc. de votre WordPress _?
J'ai un client dans la plage de 30-40k/jour sur un hôte partagé, avec une grande partie du site nécessitant une authentification à lire (nous ne pouvons donc pas faire complètement sur SuperCaching "statique" ), et ils n’ont pas encore reçu de réclamation importante concernant leur performance.
Si vous utilisez une machine dédiée avec seulement 10 000 visites supplémentaires, il se peut qu'il y ait plus d'activités qu'un serveur sous-alimenté.
APC (le cache alternatif PHP) contribuerait à économiser les cycles de traitement, car il cache le code PHP déjà compilé. Cela signifie qu'à chaque chargement de page, vos fichiers PHP ne sont pas d'abord compilés puis exécutés par la machine virtuelle, ils passent directement à la machine virtuelle PHP et l'amélioration des performances est importante (j'ai vu augmentation de la performance de 2 à 12 fois).
La prochaine étape serait d'optimiser MySQL. La première étape consiste à vérifier si vous utilisez InnoDB ou non. Si vous augmentez le buffer_pool_size de InnoDB à environ 90% de votre RAM, le jeu de données du magasin MySQL avec lequel il travaillera directement dans la RAM sera évité, de sorte que le disque IO soit évité autant que possible.
Cependant, ce que vous devriez idéalement essayer de faire est de mettre en cache toutes vos pages (je suppose que vous n'avez pas beaucoup de nouvelles choses liées au contenu postées chaque jour).
Cela nécessite probablement un peu de travail (ou il pourrait y avoir un mod WordPress là-bas, je ne suis pas vraiment sûr parce que je ne suis pas si affamé avec WP et ses plugins). La mise en cache de votre contenu réduirait la charge sur votre base de données. 40 à 50 000 vues par jour impliquent un taux de lecture élevé. Vous devez donc optimiser la lecture plutôt que l’écriture.
En outre, vous pourriez envisager de permuter vers nginx plutôt que de rester avec Apache et d'utiliser PHP FPM avec nginx. Cela devrait augmenter considérablement vos performances.
Sans voir ce qui pèse sur votre serveur (je suppose qu'Apache génère de nombreux processus accédant fréquemment à MySQL), ce sont les seules choses qui viennent à l'esprit à ce stade.
Pour un site à fort trafic, vous devez ajuster tous les tampons MySQL pour le contenu en place. Quelle que soit la version de WordPress, la configuration de la couche MySQL peut être calculée .
En fait, si vous avez des données InnoDB sans activer innodb_file_per_table, vous devez nettoyer InnoDB en segmentant chaque table dans son propre espace de table physique . Il est possible de faire un réglage MySQL décent même si votre matériel est limité . Il y a plusieurs scénarios pour réaliser de telles optimisations InnoDB .
IMHO, vous ne pouvez pas planifier de bons paramètres pour my.cnf sans connaître la quantité de données à configurer. Vous devez charger périodiquement un jeu de données actuel de la production dans un environnement intermédiaire, effectuer des optimisations et définir les nombres à configurer dans le fichier my.cnf du serveur de production.
Vous voudrez peut-être aussi vérifier si votre mise en cache se produit correctement. J'ai jeté un coup d'oeil à votre page d'accueil et ai proposé ces points -
- la plupart de vos vignettes sont redimensionnées par un script php et diffusées via votre serveur uniquement. Vous auriez pu essayer de sauver cette surcharge.
- Si vous avez des visiteurs récurrents (ce qui devrait être le cas pour votre contenu), vous devez alors mettre en œuvre la mise en cache côté navigateur afin de réduire les demandes adressées à votre serveur.
- Vous exécutez une tonne de javascripts (annonces, analyses, etc.). Pouvez-vous les différer et vous assurer que leurs js sont également mis en cache.