Max el blog Hosting Drupal
Introducción
En el pasado, y durante algunos años me he encontrado mi blog con la ayuda de Drupal, en ese momento y en los primeros meses, tengo Slashdoted y dugg tres veces, las tres veces mi servidor descendieron.
Desde entonces me he vuelto obsesionado con ajustar la configuración de mi servidor para soportar la carga de Slashdot, Digg y similares.
No estoy corriendo mi blog sobre Drupal más, pero aún así como Drupal mucho, y este fin de semana he estado jugando con Drupal 7 y barniz, para ver cómo se lleva a cabo, bajo una carga pesada.
Yo estaba tratando de encontrar una manera de optimizar la configuración de Drupal sin tener que retocar demasiado en el Drupal o la configuración del servidor, y sin la necesidad de añadir demasiados módulos "rendimiento".
El entorno
Aquí es más detalles de configuración:
- Arch Linux 2011.10
- VPS RackSpace
- 256 RAM
- Apache / PHP / MySQL / laca
Configuración
Estoy usando la instalación básica de Drupal 7, la memoria caché principal en ON.
LAMP es el estándar disponibles en Arch Linux en el momento de escribir estas líneas, y ninguna configuración especial para cualquiera de los componentes. Excepto que Apache está escuchando en el puerto 8080 en vez del puerto 80. Por lo tanto, puede páginas del servidor internamente para barniz.
El barniz es un acelerador HTTP diseñado para contenido pesado sitios web dinámicos. A diferencia de otros aceleradores HTTP, como calamar, que comenzó su vida como una memoria caché del lado del cliente, o Apache y Nginx, que son principalmente los servidores de origen, barniz fue diseñado desde el principio como un acelerador de HTTP. El barniz se centra exclusivamente en HTTP, a diferencia de otros servidores proxy que a menudo el soporte de FTP, SMTP y otros protocolos de red
Barniz va a soportar la carga, pero una vez más la configuración es bastante básico:
He utilizado la herramienta ab para probar, ya que esta es una prueba para demostrar el sitio Drupal será capaz de manejar un pico en el tráfico de Digg o John Grubber, entonces ab está bien. Si usted planea tener miles de páginas y decenas de miles de páginas vistas por horas, distribuidas en todo el contenido, esto no puede ser para usted, pero si sólo una o unas pocas páginas son populares en un momento, este es el lugar adecuado para estar .
Este es el comando:
-n: número de solicitudes -c: Número de sesiones simultáneas
Después de esto, he transferir esa misma página a un servidor Nginx se ejecuta en un espejo Arch Linux servidor de potencia.
He hecho que el uso de rizo
Y luego ejecutar ab contra Nginx con la página estática, el resultado fue:
Como se puede ver a pesar de que Drupal no está utilizando impulso, y es de contenido dinámico completo, barniz es lo que es equivalente a un sitio estático. Los resultados son casi los mismos en ambas pruebas.
Sólo para que pueda ver cómo se lleva a cabo sin barniz, esto es lo que sucede cuando se toma barniz a un lado y Apache / PHP / MySQL soporta la carga completa.
Bueno: con la misma carga, MySQL colgaron, y se detuvo todo el sistema operativo. Tuve que reiniciar el servidor desde la consola.
Por lo tanto la reducción de la carga:
Conclusión
Como se puede ver, es sólo una cuestión de instalar el barniz con una configuración muy sencilla y básica para mejorar el rendimiento del servidor mucho. Ser capaz de manejar 250 + petición por segundo en un servidor 256 MB de RAM con Drupal CMS no es tan difícil.
Una vez más, esto sólo es válida para los usuarios anónimos, es decir, si usted tiene un blog o un sitio de noticias o tutorial, donde sus visitantes no necesita estar conectado a interactuar con su contenido. Si necesita este nivel de rendimiento para los usuarios registrados, entonces usted tiene que mirar a memcached, APC y similares.
Nota: Todas las pruebas se realizaron a partir de otro dedicado servidor de la nube usando direcciones IP internas para acceder a los servidores de Nginx y Apache, así que no hay ancho de banda Limitación.
Si te ha gustado el artículo, por favor, comparta