Dans quelle mesure WordPress est-il à l'échelle?

34

Avec le nouveau WordPress et ses nouvelles fonctionnalités, il semble que WordPress soit capable de beaucoup plus qu'un simple moteur de blog. Mais à quel point la balance WordPress est-elle bien utilisée, par exemple, 10k - > 100 000 utilisateurs par jour?

Avec autant d'utilisateurs, une bonne partie de la stratégie de cache sera mise en place. Cependant, WordPress a-t-il été mis au point pour vous aider, ce qui facilite et vous donne le contrôle dont vous avez besoin. Fx peut-il mettre en cache une partie d’une page et ne restituer que les parties personnalisées, soutenir la configuration de la base de données maître / esclave, etc.?

    
posée googletorp 01.09.2010 - 09:43

3 réponses

37

Clairement, rien n'échelle, ni les fichiers statiques servis par un serveur Web rapide , ni aucun système de gestion de contenu qui doit déterminer ce qui doit être chargé puis chargé ne fonctionnera pas aussi bien, WordPress ou autre. L’un des problèmes est le nombre de requêtes de base de données requises par demande d’URL et mes 2 années d’expérience de travail exclusif avec Drupal et maintenant plus de 2 ans avec WordPress, c’est que WordPress est bien meilleur dans ce département.

Cela dit, presque rien , quel que soit le pouvoir , ne va évoluer "out-of-the-box" ; tout est question de que pouvez-vous faire à mesure que vos besoins en évolutivité grandissent?

À l'extrémité inférieure de "beaucoup de trafic" , il existe d'excellents plugins de mise en cache et des intégrations avec des CDN peu coûteux , vous pouvez faire de très bons résultats. travail avec un budget sans informatique et un budget d’hébergement bas. Voici quelques autres questions & réponses à examiner:

Il existe des options de profilage permettant d'identifier les goulots d'étranglement des performances :

Une fois les goulots d'étranglement identifiés, vous pouvez effectuer une optimisation localisée à l'aide de l'API Transients . Cette question donne un exemple qui peut être optimisé à l’aide de l’API transitoires et montre comment:

Si vous voulez vraiment sortir les gros bras , vous pouvez configurer Memcached , HyperDB , Nginx et / ou plus pour accélérer les choses (il semble que ce dernier est en train de devenir le moyen d’obtenir une étonnante extensibilité de WordPress):

Enfin, il existe des hôtes Web émergents axés sur WordPress et spécialisés dans les performances , tels que Le moteur WP , ZippyKid et autres:

Donc la bonne nouvelle est que toutes les échelles sont très bien ; libre et facile, avec une complexité technique et un coût qui ne fait que croître à mesure que le trafic croît de manière significative. Commencez petit avec WordPress et ce sera génial. Si votre trafic augmente et que vous le monétisez, même raisonnablement, vous constaterez qu'il est très rentable de le faire évoluer selon vos besoins.

Au moins IMO. :)

    
réponse donnée MikeSchinkel 01.09.2010 - 11:52
4
  1. Ne vous attendez pas à beaucoup à un hébergement partagé - ne blâmez pas WordPress pour sa lenteur si vous êtes sur un hôte partagé. Les hôtes partagés peuvent entasser des milliers de comptes sur un serveur. Donc, vous pouvez passer toute la journée à optimiser un compte à 10 $ / mois et cela n’a aucune importance. Méfiez-vous également des mots à la mode marketing - ce n'est pas parce que le mot "cloud" signifie que vous ne partagez pas un serveur avec des centaines ou des milliers de personnes.

  2. Je ne pense pas que des plugins de cache soient nécessaires à ce stade. Si vous regardez le code source de WP, il y a déjà une mise en cache avancée intégrée au noyau. Un cache du cache du cache du cache - attention, cela peut être contre-productif.

  3. La principale chose qui vous ralentit, ce sont les requêtes MySQL lentes et WordPress prêt à l'emploi ne devrait pas vous causer de problèmes ici. Cependant, je devais "limiter" mes requêtes de commentaires car j'avais plus de 50 000 commentaires. (Est-ce que cela a déjà été corrigé?) De même, si vous faites quelque chose d'atypique (comme des milliers de catégories?), Cela pourrait également poser problème.

  4. J'utilise une Linode 512 avec NginX et "top" montre que PHP et NginX font leur travail en moins de 1 / 100e de seconde par requête. Presque tout le temps processeur est lié à MySQL. Vous pourriez servir 1 million de pages par mois avec un linode à 20 dollars, mais une fois que vous aurez commencé à ajouter des plugins et des photos, vous aurez besoin d'un linode de "1 Go". De mon point de vue, c'est plutôt linéaire: Si le nombre de pages vues double, doublez simplement la taille de votre Linode.

Avertissement: je ne travaille pas pour Linode.

Mise à jour (environ 2 ans plus tard) puisque vous souhaitez mettre en cache des parties d'une page avec PHP, voici une solution simple, étonnamment rapide, que j'utilise. Je cache plusieurs parties / parties distinctes par page en 1 / 100ème de seconde. On dirait qu’un disque virtuel pourrait rendre cela encore plus rapide, mais c’est beaucoup pour mes besoins:

$cache_file = "./cache/portion-1". $since; // maybe round() this $since timestamp
$cache_life = 1000; // seconds to keep this cached
$filemtime = filemtime($cache_file);  // returns FALSE if file does not exist
if (!$filemtime or (time() - $filemtime >= $cache_life)) {

    // heavy lifting starts
    $output = 'Heavy!';
    // heavy lifting ends

    if (!file_put_contents($cache_file,$output,LOCK_EX)) { echo 'error'; } // save the cache    
    echo $output;

} else { 

    // load from cache
    $output = file_get_contents($cache_file); 
    echo $output;        
} 
    
réponse donnée PJ Brunet 24.02.2011 - 04:24
0

Il y a finalement 3 choses qui ralentissent WordPress à l’échelle, et elles se résument à ceci:

  • Pile d'hébergement - vous avez besoin d'un bon hôte avec la dernière version du logiciel - PHP 7, Nginx, Varnish, Redis, fail2ban et PerconaDB sont de bons choix
  • Pas d'analyse de table - de nombreux plugins sont écrits par des codeurs amateurs qui ne savent même pas ce qu'est une analyse de table. Deux éléments sont nécessaires pour éviter les analyses de table: un index utilisable et une requête écrite de manière à pouvoir utiliser l'index
  • Pas ou peu de requêtes SQL dans les boucles PHP - certains codes de plugins n’ont clairement été testés que sur de très petits sites. Pour une raison ou une autre, nous allons parcourir tous les produits de votre base de données et lancer un nouvel appel SQL pour chaque produit / publication. Vous voulez idéalement moins de 100 requêtes SQL par page - cela semble beaucoup, mais ce n'est pas vraiment et avec < 100, vous obtiendrez un TTFB d’environ 200 ms sans mise en cache.

Une fois que vous avez ce qui précède en place, vous pouvez ensuite ajouter la mise en cache - par exemple. Vernis, CDN, mise en cache de pages, etc.

Si vous devez faire évoluer votre système, vous pouvez créer un cluster en utilisant PerconaDB XtraDB pour la base de données et Unison pour les fichiers. De cette façon, vous pouvez avoir 1 nœud comme gestionnaire wp-admin et cron, et les autres nœuds servant le trafic Web derrière un équilibreur de charge.

    
réponse donnée Dave Hilditch 12.06.2017 - 20:35

Lire d'autres questions sur les étiquettes