it-swarm-es.com

¿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 utiliza WordPress la escala de, digamos, 10k -> 100k usuarios por día?

Con esa cantidad de usuarios, una gran parte de esto será tener una buena estrategia de caché, pero ¿qué tan bien está desarrollado WordPress para ayudar, facilitando esto y brindándole el control que necesita? ¿Fx es capaz de almacenar en caché parte de una página y solo procesar partes personalizadas por el usuario, admite configuración de db maestro/esclavo y cosas así?

34
googletorp

Claramente, nothing se escala, 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 "fuera de la caja"; se trata de ¿qué puedes hacer a medida que crecen tus necesidades de escalabilidad?

En el extremo inferior de "mucho tráfico" hay excelentes complementos de almacenamiento en caché y integraciones con CDN baratos que puede hacer un buen trabajo con un presupuesto sin TI y un bajo alojamiento presupuesto. Aquí hay algunas otras preguntas y respuestas para revisar:

Hay opciones para profiling para identificar cuellos de botella de rendimiento:

Una vez que se identifican los cuellos de botella, puede realizar optimización localizada con cosas como la Transients API. Estas preguntas y respuestas proporcionan un ejemplo que puede optimizarse utilizando la API de Transients y muestra cómo:

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

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

Entonces 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 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, aunque sea razonablemente bien, encontrará un costo muy grande a medida que lo necesite.

Al menos IMO. :)

37
MikeSchinkel
  1. No espere mucho del alojamiento compartido: no culpe a WordPress por la lentitud si está en un Host 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 punto. Si observa el código fuente de WP, ya hay un 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. Uso un Linode 512 con NginX y "top" muestra PHP y NginX haciendo 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 después), ya que quiere 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;        
} 
4
PJ Brunet

En última instancia, hay 3 cosas que reducen la velocidad de 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 todas buenas opciones
  • Sin exploraciones de tablas: muchos de los 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 PHP bucles: 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 /enviar. Lo ideal es que desee menos de 100 consultas SQL por página; parece mucho, pero en realidad no es así y con <100 obtendrá un TTFB de aproximadamente 200 ms sin adjuntar.

Una vez que tenga lo anterior en su lugar, puede agregar almacenamiento en caché, por ejemplo, Barniz, CDNs, caching de página 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.

0
Dave Hilditch