it-swarm-es.com

Experiencia en el mundo real en escala y ajuste de rendimiento

Supuestamente, 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 para el cliente y, además de obtener los servidores más grandes posibles, cuál es la mejor forma 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 yo ' Lo que estoy buscando es una experiencia real de hacer esto, qué funciona, qué no funciona y qué esperar.

52
Richard Harrison

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

Cuando tenga Pressflow para D6 o Drupal para D7, Memcached y Varnish todos trabajando bien juntos, necesitará codificar su - VCL archivo. 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. También con Varnish, tenga objetos estáticos de caché de Varnish por 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 una sola ubicación por servidor para reducir el tráfico de TCP para conexiones a varias ubicaciones 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á deteniendo Varnish y Drupal Pressflow de almacenar en caché las visitas de página 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 de ajuste http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

Tener un gran grupo de búferes es fundamentalmente importante. Al probar la carga del sitio, active el registro de consulta lento. Al principio, es probable que desee capturar consultas que demoren más de 50 ms, luego ajustar las consultas y reducir repetidamente el tiempo de captura de registro lento hasta que la mayoría de las consultas se ejecuten utilizando índices y se ejecuten con bastante rapidez.

Otros conceptos básicos implican tener APC en 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 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.

45
Stewart Robinson

Recomendaría comenzar con Pressflow (si usa Drupal 6), Memcache , Varnish , y alguna forma de la Red de distribución de contenido (CDN) como Akamai. El resultado final debería ser que la menor cantidad posible de esos usuarios realmente llegue a su servidor Origin.

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 userX", etc.), puede explorar opciones para completar estas partes de la página, como asíncrono callbacks o Edge side 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).

22
markdorison

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?

15
user49
  • 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 caché estática y persistente hasta que el registro de consulta lento salga limpio.
    • Evite PHP errores que ocurren dentro de los bucles foreach anidados a toda costa.
    • Desinstalar módulos no utilizados.
    • Active el almacenamiento en caché para Drupal bloques centrales y vistas.
  • 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.
6
amateur barista

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

5
Randy Burgess

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 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: Rápidamente , Rackspace , Akamai , Azure, CloudFlare, Amazon, MaxCDN, Verizon.

Aquí hay algunas sugerencias más:

  • Con CDN, use dominios sin cookies para componentes estáticos que se almacenarán 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 borrar cachés (usando wget, Cache Warmer , Drush ECL ).
  • Utilice la supervisión del rendimiento (por ejemplo, Nueva Reliquia o Yottaa que tienen integración para Drupal).
  • Use la herramienta de monitoreo para su sitio web (por ejemplo, Nagios).
  • Instale Varnish y módulo de integración del Acelerador HTTP Varnish , luego configúrelo .
  • Varnish + Authcache: Marque esto Ejemplo VCL para Authcache Archivo de configuración de Varnish.
  • Considere Libra o NGINX delante de Barniz. Ver: ¿Por qué Pound es impresionante frente a Barniz .
  • 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 el barniz y la libra (por ejemplo, BIG-IP F5 ).
  • Utilice 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 Drupal sugerencia de optimización, marque: ¿Cómo se mejora Drupal rendimiento?

3
kenorb

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 mucho hasta que tenga tráfico en vivo, pero si carga la prueba tanto como sea posible, al menos tendrá un cierto 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

3
Jeremy French

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.

0
James Stallings

Habilita dos extensiones:

  • Zend OPcache
  • wincache

Tu rendimiento funcionará mejor.

Si está buscando twig el Zend OPcache y Wincache en Microsoft Azure, al principio cree un nombre de carpeta ‘ini’ debajo de ‘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 tecla PHP_INI_SCAN_DIR y 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 documentación de Microsoft .

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

0
npcoder