Experiencia en el mundo real en escalado y ajuste de rendimiento

El sitio web en el que estoy trabajando tendrá una tasa de éxito masiva poco después del lanzamiento . El cliente está hablando de la posibilidad de alrededor de 2500 visitas por segundo durante un día más o menos.

Ignorando el hecho de que esta tasa de aciertos probablemente sea un optimismo salvaje del cliente y, además de obtener los servidores más grandes posibles, ¿cuál es la mejor manera en que Drupal debería configurarse para admitir una gran tasa de aciertos?

He leído Scaling the drupal.org Infrastructure , Drupal performance blog , Best Practices for Scaling Drupal y muchas otras páginas, pero lo que estoy buscando es una experiencia real de hacer esto, qué funciona, qué no funciona y qué esperar.

La respuesta de Markdorison es básicamente el método aceptado para atacar este problema. Lo llevaré un poco más allá.

Cuando tiene Pressflow para D6 o Drupal para D7, Memcached y Varnish funcionan bien juntos, necesitará codificar su archivo VCL de forma personalizada . Hay algunos gratuitos disponibles que hacen puntos de partida, pero siempre necesitas jugar con ellos.

Para que Varnish funcione de manera óptima, asegúrese de iniciarlo con -s malloc xG en lugar del valor predeterminado de -s file / path / to / file. Además, con Varnish, tenga elementos estáticos de caché de Varnish durante el mayor tiempo posible.

Si tiene más de un servidor web, elimine la ETag del encabezado enviado a Varnish en VCL. También elimino Expires y simplemente confío en Age y max-age en los encabezados para que los navegadores vuelvan al sitio.

La versión 1.5 (a partir del 3 de marzo de 2011) sigue siendo la versión más rápida del módulo Memcached de Drupal.org. Normalmente lo implemento usando un único contenedor por servidor para reducir el tráfico tcp para conexiones a múltiples contenedores a gran escala)

Configure el almacenamiento en caché en "Rendimiento" como externo y establezca una antigüedad máxima que enviará los encabezados correctos a un proxy de almacenamiento en caché como Varnish.

Si no puede hacer que ciertas páginas se almacenen correctamente en Varnish, consulte las publicaciones de blog en la web que detallan cómo inspeccionar las solicitudes. Aquí hay una publicación de ejemplo que escribí hace un tiempo: ¿Qué está impidiendo que Varnish y Drupal Pressflow almacenen en caché vistas de páginas de usuarios anónimos?

Debe elegir InnoDB (o uno de sus otros nombres de otros proveedores como XtraDB) para MySQL y mover todas las tablas a él. Luego, consulte esta publicación de blog para obtener consejos básicos sobre la sintonización http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

Tener una gran agrupación de almacenamiento intermedio es fundamentalmente importante. Al probar la carga del sitio, active el registro lento de consultas. Es probable que al principio desee capturar consultas que demoren más de 50 ms, luego ajustar las consultas y reducir de manera repetitiva el tiempo de captura de registro lento hasta que tenga la mayoría de las consultas en ejecución utilizando índices y ejecutándose con bastante rapidez.

Otros conceptos básicos implican tener APC para PHP. Si opta por un CGI rápido en lugar de mod_php, dedique un tiempo a intentar que la caché APC se comparta entre las instancias de php configurando un buen script de envoltura. También asegúrese de que el caché APC esté en un archivo mapeado de memoria para exprimir hasta el último bit de PHP.

Recomendaría comenzar con Pressflow (si usa Drupal 6), Memcache , Varnish y alguna forma de Content Distribution Network (CDN) como Akamai. El resultado final debería ser el menor número posible de usuarios que realmente lleguen a su servidor de origen.

Si tiene partes de la página que no puede almacenar en caché para usuarios no anónimos (cosas que son específicas de ese usuario, "Bienvenido usuario X", etc.), puede explorar opciones para llenar estas partes de la página, como asíncrono callbacks o edge edge incluye.

Si tiene un grupo más pequeño de usuarios internos (como un grupo de editores) que necesitan poder ver una versión sin caché del sitio, recomendaría exponer una versión sin caché de su sitio en una URL diferente (protegida detrás de una VPN o equivalente si es posible).

2500 visitas por segundo durante un día: si por "visita" se refiere a "página entregada", eso es 216 millones de páginas por día. Déjame decirte esto: no tienes 216 millones de páginas al día. Amo a estos clientes ...

Dicho esto, los datos de tráfico sin procesar no dicen nada. Si bien el consejo en este hilo es sólido sobre Varnish / CDN si todo lo que tiene es tráfico anónimo, pero si ha iniciado sesión en el tráfico, se enfrenta a un desafío. Pero antes de gastar una cantidad de tiempo y esfuerzo impíos para resolver un problema, asegúrese de tener un problema. 2500 golpes por segundo, Bing obtiene menos que eso, te das cuenta de eso, ¿verdad?

• Lado del servidor

  • Instale Varnish para el almacenamiento en caché de páginas para usuarios anónimos.
  • Instale un sistema de caché persistente (Memcached, APC, Memcache).
  • Use un CDN como Akamai para servir archivos estáticos (JavaScript, CSS, imágenes).

• Lado del código

  • Use Pressflow, permite que Varnish sirva la página en caché para usuarios anónimos.
  • Limpia la mesa de vigilancia de Drupal. Cada vez que se registra un error de vigilancia, consume recursos de la CPU en el servidor web y el servidor de la base de datos. También aumenta significativamente el tiempo de carga.
  • Implemente estrategias de caché estáticas y persistentes hasta que el registro de consulta lento salga limpio.
  • Evite los errores de PHP que ocurren dentro de los bucles foreach anidados a toda costa.
  • Desinstalar módulos no utilizados.
  • Active el almacenamiento en caché para los bloques centrales y las vistas de Drupal.

• Base de datos

  • Asegúrese de que las tablas estén indexadas correctamente para una búsqueda más rápida.
  • No almacene registros innecesarios, siempre se accederá a una base de datos de 100 nodos más rápido que a una base de datos de 3 millones de nodos.

También escucharía este podcast de Lullabot sobre la forma en que configuraron el sitio web Grammys.com para una explosión de tráfico en el transcurso de una semana. Fue una explicación bastante educativa.

http://www.lullabot.com/podcasts/podcast-92-grammycom

Si bien es muy difícil predecir patrones, si tiene una idea clara de los niveles de tráfico. Prueba de carga tu solución. Hay una gran cantidad de opciones diferentes y no será posible predecir muchas cosas hasta que tenga tráfico en vivo, pero si carga la prueba tanto como sea posible, al menos tendrá un alto grado de confianza en que su configuración puede manejar el tráfico.

Todos los ajustes en el mundo no ayudarán si no lo prueba primero.

Esta fue una presentación en DC SF sobre cómo lo hizo el economista. http://sf2010.drupal.org/conference/sessions/performance-testing-economist-online-using-grinder

Para sitios web de alto tráfico, debe usar varios servidores y equilibrador de carga o simplemente usar CDN. También es muy importante almacenar en caché tanto como sea posible para minimizar la carga en los servidores web.

El uso de Content Delivery Network ( CDN ) ayuda a distribuir los recursos en varios dominios (fragmentación de dominio), lo que reduce la carga en el servidor web.

El uso de CDN ayuda con el almacenamiento en caché distribuido y la aceleración remota, también ayuda a mitigar los ataques DDoS , debido a múltiples puntos finales. Ayuda con la seguridad, porque el contenido en caché es más difícil de explotar.

Proveedores de ejemplo: Fastly , Rackspace , Akamai , Azure, CloudFlare, Amazon, MaxCDN, Verizon.

Aquí hay algunas sugerencias más:

• Con CDN, use dominios sin cookies para que los componentes estáticos se almacenen en caché (como sstatic.net ). Dado que algunos servidores proxy pueden negarse a almacenar en caché los componentes que se solicitan con cookies.
• Caliente sus cachés después de limpiar los cachés (usando wget, Cache Warmer , Drush ECL ).
• Utilice la supervisión del rendimiento (por ejemplo, New Relic o Yottaa que tienen integración para Drupal).
• Use la herramienta de monitoreo para su sitio web (por ejemplo, Nagios).
• Instale el módulo Varnish y Varnish HTTP Accelerator Integration , luego configúrelo .
• Varnish + Authcache: Verifique este ejemplo VCL para el archivo de configuración Authcache Varnish.
• Considere Libra o NGINX delante de Barniz. Ver: ¿Por qué Pound es increíble frente a Varnish ?
• NGINX puede funcionar como proxy inverso y equilibrador de carga, por lo que puede reemplazar a Pound y Varnish.
• Considere una versión comercial de Varnish o NGINX para utilizar funciones que no están disponibles en la versión de código abierto de "comunidad".
• Considere el equilibrador de carga / almacenamiento en caché de hardware para reemplazar Barniz y Libra (por ejemplo, BIG-IP F5 ).
• Use herramientas como ab, JMeter para TTFB , pruebas de carga y estrés en su aplicación web.

Entonces su arquitectura web desde el punto de vista del usuario puede verse así:

1. Usuario (almacenamiento en caché del navegador local).
2. NGINX o Pound + Varnish (equilibrador de carga, proxy inverso como acelerador HTTP).
3. Apache (servidor web).
4. PHP-FPM (PHP FastCGI Process Manager).
5. MariaDB (base de datos).

Para sugerencias de optimización de Drupal, verifique: ¿Cómo mejora el rendimiento de Drupal?

Habilita dos extensiones:

• Zend OPcache
• wincache

Tu rendimiento funcionará mejor.

Si está buscando ramitar el Zend OPcache y Wincache en Microsoft Azure, al principio cree un nombre de carpeta ' ini' debajo ' D:\home\site\'. Además, cree 2 archivos, ' .user.ini' y ' settings.ini'

Agregue la siguiente configuración en cada archivo:

.user.ini

[PHP]
post_max_size = 32M
memory_limit = 512M
zend.enable_gc = On
upload_max_filesize = 32M
opcache.enable=1

setting.ini

wincache.ocenabled = 1
wincache.ocachesize = 255

Además, agregue una configuración de aplicación a su aplicación web con la clave PHP_INI_SCAN_DIR y el valor d:\home\site\ini

Después de cambiar PHP_INI_SYSTEM, reinicie su aplicación web. Si desea obtener más información sobre la configuración de ramitas, consulte la documentación de Microsoft .

Después de la configuración anterior, mi sitio Drupal (Drupal 8.3) se carga en 3 segundos.

También puede examinar la redistribución de la carga en varios servidores con la ayuda de una solución de equilibrio de carga basada en DNS o software / hardware. Esto también provocaría tolerancia a fallas.