web-dev-qa-db-fra.com

À quel point WordPress est-il à l'échelle?

Avec le nouveau WordPress et ses nouvelles fonctionnalités, il semble que WordPress est capable de beaucoup plus qu'un simple moteur de blog. Mais dans quelle mesure la balance WordPress utilisée par 10 000 utilisateurs -> 100 000 par jour?

Avec autant d'utilisateurs, une bonne partie de la stratégie de cache sera mise en place, mais WordPress a été développé pour vous aider, ce qui facilite cette tâche 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.?

performancecachescale
34
googletorp

Clairement rien ne s’adapte aussi bien que les fichiers statiques servis par un serveur Web rapide et tout CMS 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 requête d'URL et mes 2 années d'expérience de travail exclusivement 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 avec aucun pouvoir va évoluer "out-of-the-box"; tout tourne autour de que pouvez-vous faire à mesure que vos besoins en évolutivité grandissent?

Sur le bas de "beaucoup de trafic" il y a d'excellents plugins de mise en cache et des intégrations avec des CDN peu coûteux vous pouvez faire un très bon travail sur un no-IT budget et budget d'hébergement bas. Voici d'autres questions et réponses à examiner:

Il existe des options pour profiling permettant d'identifier les goulots d'étranglement des performances :

Une fois que les goulots d'étranglement sont identifiés, vous pouvez utiliser optimisation localisée avec des éléments tels que l'API Transients . Cet article donne un exemple qui peut être optimisé à l'aide de l'API transitoire et montre comment:

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

Et enfin, il y a des hôtes Web émergents axés sur WordPress et spécialisés dans la performance tels que WP Engine , ZippyKid et d'autres:

Donc la bonne nouvelle concerne toutes les échelles ; libre et facile, avec la complexité technique et le coût, ne font 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 s'adapter à mesure que vous en avez besoin.

Au moins IMO. :)

37
MikeSchinkel

  1. Ne vous attendez pas à beaucoup de l'hébergement partagé - ne blâmez pas WordPress pour la 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. Faites également attention aux mots à la mode marketing - ce n'est pas parce que le mot "cloud" ("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 WP, il y a déjà une mise en cache avancée intégrée dans le noyau. Cache du cache du cache du cache - attention, cela peut être contre-productif.

  3. La principale chose qui vous ralentit est la lenteur des requêtes MySQL 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 plus, 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 PHP et NginX faisant leur travail en moins d'un centième 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 USD, mais une fois que vous aurez commencé à ajouter des plugins et des photos, vous aurez besoin d'un Linode "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.

Disclaimer: Je ne travaille pas pour Linode.

Mise à jour (~ 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 mémoire pourrait rendre cela encore plus rapide, mais c'est beaucoup plus rapide 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;        
}
4
PJ Brunet

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 - beaucoup de 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 à l'intérieur des boucles PHP - certains codes de plug-ins n'ont clairement été testés que sur de très petits sites. /poster. 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 non mis 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 page, etc.

Si vous devez faire évoluer votre système, vous pouvez créer un cluster 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.

0
Dave Hilditch