¿Qué tan bien escala WordPress?

Con el nuevo WordPress y sus nuevas características, parece que WordPress es capaz de mucho más que un simple motor de blog. Pero, ¿qué tan bien escala WordPress siendo utilizado por digamos 10k -> 100k usuarios por día?

Con tantos usuarios, una gran parte de esto será tener una buena estrategia de caché, pero qué tan bien está desarrollado WordPress para ayudarlo, haciendo que esto sea fácil y le brinde el control que necesita. ¿FX puede almacenar en caché parte de una página y solo renderizar partes personalizadas por el usuario, admitir la configuración de db maestro / esclavo y cosas así?

Claramente, nada escala tan bien como los archivos estáticos servidos por un servidor web rápido y cualquier CMS que tenga que averiguar qué cargar y luego cargar no funcionará tan bien, WordPress o de otro modo. Uno de los problemas es la cantidad de consultas de base de datos requeridas por solicitud de URL y mi experiencia de 2 años anteriores trabajando exclusivamente con Drupal y ahora más de 2 años con WordPress es que WordPress es mucho mejor en ese departamento.

Dicho esto, casi nada con ningún poder va a escalar "fuera de la caja" ; ¿se trata de qué puede hacer a medida que crecen sus necesidades de escalabilidad?

En el extremo bajo de "mucho tráfico" hay excelentes complementos de caché e integraciones con CDN de bajo costo , puede hacer un trabajo bastante bueno con un presupuesto sin TI y un bajo presupuesto de alojamiento. Aquí hay algunas otras preguntas y respuestas para revisar:

• Pasos para optimizar WordPress con respecto a la carga del servidor?
• ¿Opciones para CDN con WordPress incluyendo complementos de soporte?
• ¿Configurar WordPress para el almacenamiento en caché de Amazon CloudFront?

Hay opciones para crear perfiles para identificar cuellos de botella en el rendimiento :

• ¿Perfilando un sitio web de WordPress para su implementación en hosting compartido?

Una vez que se identifican los cuellos de botella, puede hacer una optimización localizada con cosas como la API de transitorios . Estas preguntas y respuestas ofrecen un ejemplo que se puede optimizar con la API de transitorios y muestra cómo:

• ¿Usando WP_Query para consultar varias categorías con publicaciones limitadas por categoría?

Si realmente desea sacar las armas grandes, puede configurar Memcached , HyperDB , Nginx y / o más para acelerar las cosas (parece que este último realmente está evolucionando hacia la forma de obtener una escalabilidad increíble de WordPress):

• Habilite Memcached para su WordPress
• Cómo acelerar WordPress con Nginx y WP Super Cache
• HyperDB
• Nginx como caché de proxy front-end para WordPress

Y, por último, están surgiendo servidores web centrados en WordPress especializados en rendimiento como WP Engine , ZippyKid y otros:

• ¿Las mejores características de un proveedor de alojamiento web de WordPress de alta gama?

Así que la buena noticia es que todas las escalas están muy bien ; desde el extremo más bajo de forma gratuita y fácil con la complejidad técnica y el costo solo crece a medida que el tráfico crece significativamente. Comience con WordPress y será genial. Si su tráfico crece y lo está monetizando, incluso razonablemente bien, le resultará muy rentable escalar según lo necesite.

Al menos de la OMI. :)

1. No esperes mucho del alojamiento compartido: no culpes a WordPress por la lentitud si estás en un host compartido. Los hosts compartidos pueden acumular miles de cuentas en un servidor. Por lo tanto, puede pasar todo el día optimizando una cuenta de $ 10 / mes y no importará. También tenga cuidado con las palabras de moda de marketing, solo porque dice "nube" no significa que no esté compartiendo un servidor con cientos o miles de personas.

2. No creo que los complementos de caché sean necesarios en este momento. Si observa el código fuente de WP, ya hay almacenamiento en caché avanzado en el núcleo. Un caché del caché del caché del caché: cuidado, esto puede ser contraproducente.

3. Lo principal que te ralentiza es que las consultas MySQL lentas y WordPress listo para usar no deberían darte problemas aquí. Sin embargo, tuve que "LIMITAR" mis consultas de comentarios porque tenía más de 50,000 comentarios. (¿Ya se ha solucionado?) Además, si está haciendo algo atípico (¿como miles de categorías?), Eso también podría ser un problema.

4. Utilizo un Linode 512 con NginX y "top" muestra que PHP y NginX realizan su trabajo en menos de 1/100 de segundo por solicitud. Casi todo el tiempo de CPU está vinculado con MySQL. Podrías servir 1 millón de páginas por mes con un Linode de $ 20, pero una vez que comiences a agregar complementos y fotos, creo que necesitarás un Linode de "1GB". Desde mi punto de vista, es bastante lineal: si las páginas vistas se duplican, simplemente duplique el tamaño de su Linode.

Descargo de responsabilidad: no trabajo para Linode.

Actualización (~ 2 años después) ya que desea almacenar en caché partes de una página con PHP, aquí hay una solución simple que utilizo que es sorprendentemente rápida. Estoy almacenando varias partes / porciones por página en 1/100 de segundo. Parece que un ramdisk podría hacer esto aún más rápido, pero es bastante rápido para mis necesidades:

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

En última instancia, hay 3 cosas que ralentizan WordPress a escala, y se reducen a esto:

• Pila de hosting: necesita un buen host con el software más reciente: PHP 7, Nginx, Varnish, Redis, fail2ban y PerconaDB son buenas opciones
• Sin escaneos de tablas: muchos complementos están escritos por codificadores aficionados que ni siquiera saben qué es un escaneo de tablas. Se necesitan dos cosas para evitar escaneos de tabla: un índice utilizable y una consulta escrita de tal manera que pueda usar el índice
• Ninguna o pocas consultas SQL dentro de los bucles PHP: es evidente que algunos códigos de complementos solo se han probado en sitios pequeños, y por una razón u otra recorrerán cada producto en su base de datos y harán una nueva llamada SQL para cada producto / publicación. Lo ideal es que desee menos de 100 consultas SQL por página, parece mucho, pero en realidad no lo es y con <100 obtendrá un TTFB de alrededor de 200 ms sin caché.

Una vez que tenga lo anterior en su lugar, puede agregar el almacenamiento en caché, por ejemplo, barniz, CDN, almacenamiento en caché de páginas, etc.

Si necesita escalar, puede crear un clúster utilizando PerconaDB XtraDB para la base de datos y Unison para los archivos. De esa manera, puede tener 1 nodo como su wp-admin y cron runner, y los otros nodos que sirven el tráfico web detrás de un equilibrador de carga.