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

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 dans quelle mesure la balance WordPress utilisée par 10 000 -> 100 000 utilisateurs par jour?

Avec autant d'utilisateurs, une bonne partie de la stratégie de cache sera mise en place, mais à quel point WordPress a-t-il é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 maître / esclave de la base de données, etc.?

Il est clair que rien ne se met à l'échelle, ainsi que les fichiers statiques servis par un serveur Web rapide et tout système de gestion de contenu qui doit déterminer ce qu'il faut charger, puis le charger ne fonctionnera pas aussi bien, que ce soit avec 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 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, ne se propage à l’échelle "d’emblée" ; tout est question de ce que vous pouvez faire à mesure que vos besoins en évolutivité grandissent?

Sur le segment bas 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 un très bon travail avec un budget sans informatique et un budget d'hébergement bas. Voici d'autres questions et réponses à examiner:

• Étapes pour optimiser WordPress par rapport à la charge du serveur?
• Options pour CDN avec WordPress, y compris les plugins de support?
• Configuration de WordPress pour la mise en cache Amazon CloudFront?

Le profilage permet d’identifier les goulots d’étranglement liés aux performances :

• Profiler un site Web WordPress pour le déploiement sur un hébergement partagé?

Une fois que les goulots d'étranglement sont identifiés, vous pouvez effectuer une optimisation localisée à l' aide d'é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:

• Utilisation de WP_Query pour interroger plusieurs catégories avec un nombre limité de publications par catégorie?

Si vous obtenez chose vraiment besoin de sortir les gros canons , vous pouvez configurer Memcached , HyperDB , Nginx et / ou plus pour accélérer les choses (il semble que ce dernier est en train d' évoluer vraiment dans la façon d'obtenir une évolutivité étonnante de WordPress):

• Activer Memcached pour votre WordPress
• Comment accélérer WordPress avec Nginx et WP Super Cache
• HyperDB
• Nginx en tant que cache de proxy frontal pour WordPress

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

• Les meilleures caractéristiques d'un hébergeur Web WordPress haut de gamme?

La bonne nouvelle est donc très belle . 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. :)

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 de 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 que PHP et NginX travaillent en moins d'un centième de seconde par demande. 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.

Disclaimer: 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 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;        
} 

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 dans les boucles PHP - certains codes de plugins n'ont clairement été testés que sur des sites minuscules. 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 non mis en cache.

Une fois que vous avez mis en place ce qui précède, vous pouvez alors ajouter une mise en cache - par exemple Varnish, 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.