¿Qué tan bien escala WordPress?

Es evidente que no se puede escalar, así 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 otra manera. 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 cualquier poder va a escalar "out-of-the-box" ; se trata de ¿qué puedes hacer a medida que aumentan tus necesidades de escalabilidad?

En el extremo inferior de "mucho tráfico" hay excelentes complementos de almacenamiento en caché y integraciones con CDN económicos que puedes hacer bastante bien trabajo en un presupuesto sin TI y bajo presupuesto de alojamiento. Aquí hay algunas otras preguntas & Respuestas a la reseña:

• Pasos para optimizar WordPress en relación con la carga del servidor ?
• Opciones para CDN con WordPress ¿Incluye complementos compatibles?
• ¿Configurando WordPress para Amazon CloudFront Caching?

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

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

Una vez que se identifican los cuellos de botella, puede hacer optimización localizada con cosas como la API de transitorios . Esta Q & A da un ejemplo que se puede optimizar utilizando la API de Transients y muestra cómo:

• Uso de WP_Query para consultar múltiples categorías con publicaciones limitadas por categoría ?

Si realmente quieres sacar las armas grandes puedes configurar Memcached , HyperDB , Nginx y / o más para acelerar las cosas (parece que esto ú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 un frente cache de proxy final para WordPress

Y, finalmente, hay servidores web centrados en WordPress emergentes especializados en rendimiento como WP Engine , ZippyKid y otros:

• Mejor de su clase características de un servidor web de WordPress de alta gama?

Entonces la buena noticia es que todas las escalas están muy bien ; desde el extremo más bajo de fácil y gratuito, con complejidad técnica y costo, solo crece a medida que el tráfico crece significativamente. Comience poco a poco con WordPress y será genial. Si su tráfico crece y lo está monetizando incluso razonablemente bien, encontrará un costo muy grande a medida que lo necesite.

Al menos IMO. :)

1. No esperes mucho del alojamiento compartido. No culpes a WordPress por la lentitud si estás en un servidor compartido. Los hosts compartidos pueden agrupar 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 existe un almacenamiento en caché avanzado integrado en el núcleo. Una memoria caché de la memoria caché de la memoria caché de la memoria caché: cuidado, esto puede ser contraproducente.

3. Lo que más te ralentiza es la lentitud en las consultas de MySQL y WordPress no debería causar problemas aquí. Sin embargo, tuve que "LIMITAR" mis consultas de comentarios porque tenía más de 50,000 comentarios. (¿Ya está solucionado?) Además, si está haciendo algo atípico (como 1000 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á relacionado con MySQL. Puedes servir 1 millón de páginas al 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 visitas a la página se duplican, simplemente duplique el tamaño de su Linode.

Descargo de responsabilidad: no trabajo para Linode.

Actualice (~ 2 años más tarde), ya que desea guardar en caché partes de una página con PHP, aquí hay una solución simple que utilizo que es sorprendentemente rápida. Estoy almacenando en caché varias partes / porciones separadas por página dentro de la centésima parte de un 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 reducen la velocidad de WordPress a escala, y se reducen a esto:

• Pila de alojamiento: necesita un buen servidor con el último software: PHP 7, Nginx, Varnish, Redis, fail2ban y PerconaDB son todas buenas opciones
• Sin exploraciones de tablas: muchos complementos están escritos por programadores aficionados que ni siquiera saben qué es una exploración de tablas. Se necesitan dos cosas para evitar las exploraciones de tablas: un índice utilizable y una consulta escrita de tal manera que pueda usar el índice.
• Ninguna o pocas consultas de SQL dentro de los bucles de PHP: algunos códigos de complementos claramente solo se han probado en sitios pequeños, y por una razón u otra recorrerán todos los productos de su base de datos y realizarán una nueva llamada a 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ás un TTFB de alrededor de 200 ms sin cachear.

Una vez que tenga lo anterior en su lugar, puede agregar 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 wp-admin y cron runner, y los otros nodos que sirven tráfico web detrás de un equilibrador de carga.