¿Qué tan bien escala WordPress?

34

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, por ejemplo, 10k - > 100k usuarios por día?

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

    
pregunta googletorp 01.09.2010 - 09:43

3 respuestas

37

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:

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

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:

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):

Y, finalmente, hay servidores 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 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. :)

    
respondido por el MikeSchinkel 01.09.2010 - 11:52
4
  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;        
} 
    
respondido por el PJ Brunet 24.02.2011 - 04:24
0

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.

    
respondido por el Dave Hilditch 12.06.2017 - 20:35

Lea otras preguntas en las etiquetas