Quanto bene scala WordPress?

Con il nuovo WordPress e le sue nuove funzionalità, sembra che WordPress sia in grado di fare molto di più di un semplice motore di blog. Ma quanto bene viene utilizzato il ridimensionamento di WordPress per dire 10k -> 100k utenti al giorno?

Con così tanti utenti sarà una buona parte avere una buona strategia cache, ma quanto WordPress è stato sviluppato per aiutare, rendendolo facile e dandoti il ​​controllo di cui hai bisogno. Fx essere in grado di memorizzare nella cache parte di una pagina e renderizzare solo parti personalizzate dell'utente, supportare la configurazione db master / slave e cose del genere?

Chiaramente nulla si ridimensiona, così come i file statici serviti da un veloce web server e qualsiasi CMS che deve capire cosa caricare e quindi caricarlo non funzionerà altrettanto, WordPress o altro. Uno dei problemi è il numero di query di database richieste per richiesta URL e la mia esperienza di 2 anni precedenti lavorando esclusivamente con Drupal e ora 2+ anni con WordPress è che WordPress è molto meglio in quel reparto.

Detto questo, quasi nulla con alcun potere ridimensionerà "out-of-the-box" ; si tratta di cosa puoi fare man mano che crescono le tue esigenze di scalabilità?

Nella fascia bassa di "un sacco di traffico" ci sono ottimi plugin di cache e integrazioni con CDN economici che puoi fare un buon lavoro con un budget senza IT e un budget di hosting basso. Ecco alcune altre domande e risposte da recensire:

• I passaggi per ottimizzare WordPress per quanto riguarda il carico del server?
• Opzioni per CDN con WordPress incluso plug-in di supporto?
• Configurare WordPress per Amazon CloudFront Caching?

Esistono opzioni di profilazione per identificare i colli di bottiglia delle prestazioni :

• Profilare un sito Web WordPress per la distribuzione su hosting condiviso?

Una volta identificati i colli di bottiglia, puoi eseguire l' ottimizzazione localizzata con cose come l' API Transients . Queste domande e risposte forniscono un esempio che può essere ottimizzato utilizzando l'API Transients e mostra come:

• Utilizzo di WP_Query per eseguire query su più categorie con post limitati per categoria?

Se vuoi davvero estrarre le grandi pistole puoi configurare Memcached , HyperDB , Nginx e / o altro per accelerare le cose (sembra che quest'ultimo si stia davvero evolvendo nel modo di ottenere una straordinaria scalabilità da WordPress):

• Abilita Memcached per il tuo WordPress
• Come velocizzare WordPress con Nginx e WP Super Cache
• HyperDB
• Nginx come cache proxy front-end per WordPress

E infine ci sono webhost emergenti focalizzati su WordPress specializzati in prestazioni come WP Engine , ZippyKid e altri:

• Funzionalità best-of-Breed di un host web WordPress di fascia alta?

Quindi le buone notizie sono tutte le scale molto bene ; dalla fascia più bassa di libero e facile con complessità tecnica e costi crescono solo quando il traffico aumenta in modo significativo. Inizia in piccolo con WordPress e sarà fantastico. Se il tuo traffico cresce e lo stai monetizzando anche ragionevolmente bene, troverai un effetto molto conveniente ridimensionare quando ne hai bisogno.

Almeno IMO. :)

1. Non aspettarti molto dall'hosting condiviso: non incolpare WordPress per la lentezza se sei su un host condiviso. Gli host condivisi potrebbero raggruppare migliaia di account in un server. Quindi puoi passare tutto il giorno a ottimizzare un account da $ 10 al mese e non importa. Fai attenzione anche alle parole d'ordine del marketing, solo perché dice "cloud" non significa che non stai condividendo un server con 100 o 1000 persone.

2. Non credo che i plug-in di cache siano necessari a questo punto. Se guardi il codice sorgente di WP, c'è già una cache avanzata integrata nel core. Una cache della cache della cache della cache - attenzione, questo può essere controproducente.

3. La cosa principale che ti rallenta sono le query MySQL lente e WordPress pronto per l'uso non dovrebbe darti problemi qui. Tuttavia, ho dovuto "LIMITARE" le mie domande di commento perché avevo più di 50.000 commenti. (È già stato risolto?) Inoltre, se stai facendo qualcosa di atipico (come migliaia di categorie?) Che potrebbe anche essere un problema.

4. Uso un Linode 512 con NginX e "top" mostra PHP e NginX che fanno il loro lavoro in meno di 1/100 di secondo per richiesta. Quasi tutto il tempo della CPU è legato a MySQL. Potresti servire 1 milione di pagine al mese con un Linode da $ 20, ma una volta che inizi ad aggiungere plugin e foto, penso che avrai bisogno di un Linode "1GB". Dal mio punto di vista, è praticamente lineare: se le visualizzazioni di pagina raddoppiano, basta raddoppiare le dimensioni del Linode.

Disclaimer: non lavoro per Linode.

Aggiornamento (~ 2 anni dopo) poiché vuoi memorizzare nella cache parti di una pagina con PHP, ecco una semplice soluzione che uso sorprendentemente veloce. Sto memorizzando nella cache diverse parti / porzioni separate per pagina entro 1/100 di secondo. Sembra che un ramdisk potrebbe renderlo ancora più veloce ma è molto veloce per le mie esigenze:

$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;        
} 

Alla fine ci sono 3 cose che rallentano WordPress su larga scala e si riducono a questo:

• Stack di hosting: hai bisogno di un buon host con il software più recente: PHP 7, Nginx, Varnish, Redis, fail2ban e PerconaDB sono tutte buone scelte
• Nessuna scansione della tabella: molti plugin sono scritti da programmatori amatoriali che non sanno nemmeno cosa sia una scansione della tabella. Per evitare scansioni di tabelle sono necessari due elementi: un indice utilizzabile e una query scritta in modo tale da poter utilizzare l'indice
• Nessuna o poche query SQL all'interno dei loop PHP: alcuni codici plug-in sono stati chiaramente testati solo su piccoli siti e, per un motivo o per l'altro, eseguiranno il ciclo di tutti i prodotti nel database e effettueranno una nuova chiamata SQL per ogni prodotto / post. Idealmente, vuoi meno di 100 query SQL per pagina - sembra molto, ma non lo è davvero e con <100 otterrai un TTFB di circa 200ms non memorizzato nella cache.

Dopo aver impostato quanto sopra, è possibile aggiungere la memorizzazione nella cache, ad esempio Varnish, CDN, cache della pagina ecc.

Se è necessario ridimensionare, è possibile creare un cluster utilizzando PerconaDB XtraDB per il database e Unison per i file. In questo modo, puoi avere 1 nodo come wp-admin e cron runner e gli altri nodi che servono il traffico web dietro un bilanciamento del carico.