Pruebas de rendimiento servidores Foto DNG

Foto DNG desde el inicioServidor en Serverpronto con Apache, MySQL y PHP:● FreeBSD 5.3 256Mb. de RAM (2006)● FreeBSD 7.1 2Gb. de RAM (Marzo 2009)Cambio a servidor en OVH con Nginx, MySQL y PHP (Diciembre 2009):● Ubuntu Server varias versiones, desde 4Gb. de

RAM el primero hasta 16Gb. de RAM el actual.

Foto DNG desde el inicio● Diciembre del 2007, primera entrada del Blog

de Foto DNG (en Blogger).● Agosto del 2011, el Blog pasa a nuestros

servidores, con WordPress bajo el directorio /blog/.

● Junio del 2013, la web de Foto DNG y el Blog se integran en uno, bajo WordPress y plug-ins propios (el mayor cambio interno desde el nacimiento de la web de Foto DNG).

Próximos cambios y pruebas en Foto DNG

Foto DNG en virtual serverGracias a Miguel Ángel, amigo y CEO de On Services,

llevamos algo más de un mes realizando pruebas sobre una máquina virtual (con 8Gb. de RAM)

Foto DNG en virtual server● Cambio de Nginx v 1.2.1 a 1.4.1 con módulo

fastcgi_cache_purge (repositorio ppa:brianmercer/nginx).

● Cambio de PHP (fpm) de v 5.4.6 a 5.5.6, Zend Engine de 2.4.0 a 2.5.0 (repositorio ppa:ondrej/php5).

● En vez del uso de la extensión de PHP APC (v3.1.13) se cambia al interno de PHP 5.5 que es Zend OPcache v7.0.3-dev.

● Cambio de MySQL v5.5.35 a MariaDB v5.5.34

Foto DNG en virtual server● Instalación de la extensión de WordPress Nginx-helper

para la administración de caché de Nginx● Uso de W3Total Cache,en esta instalación sin caché de

páginas en el servidor (que relegamos a Nginx).● Optimización de MariaDB con los scripts mysqlreport,

mysqltuner y tunning-primer.● Optimización de pool de php5-fpm.

Ventajas obtenidas

● Si no se ejecuta PHP, las páginas siguen mostrándose debido a que se sirven desde caché de Nginx mediante fastcgi_cache

● Al servirse en la mayoría de los casos páginas HTML sin el uso de PHP, aumenta considerablemente el número de páginas que se pueden servir por segundo.

Las pruebas del servidor

Pruebas realizadas con Apache Benchmark

● Las pruebas se han realizado con 50.000 peticiones al nuevo servidor y sin la opción -k de Keep Alive.

● Las pruebas se han realizado desde un servidor alternativo en OVH (2Gb. de RAM) hacia el nuevo servidor en On Services.

● Se han realizado 10 pruebas desde 100 usuarios simultáneos hasta 1.000 usuarios simultáneos.

● Se han realizado tres pruebas contra el servidor actual en OVH (desde 100 hasta 300 usuarios simultáneos).

Pruebas realizadas con Apache Benchmark

El comando ejecutado ha sido:

# ab -c 100 -n 50000 http://nuevo.server.com/ > resultados100.txt# ab -c 200 -n 50000 http://nuevo.server.com/ > resultados200.txt….

Pruebas realizadas con Apache Benchmark

Servidor Actual:● Con 100 peticiones simultáneas ha producido 5 fallos.● Aumentando las peticiones simultáneas empieza a

fallar php-fpm y fallar la mayoría de las páginas servidas.

● El servicio php-fpm se vuelve a ejecutar gracias a Monit.

Pruebas realizadas con Apache Benchmark

Servidor de Pruebas On-Services:● Hasta 600 peticiones simultáneas no se han producido

fallos (104 fallos en 600).● Con 1.000 peticiones simultáneas los fallos se disparan

hasta 49.036 (de las 50.000 peticiones), por lo que para poder apreciar la gráfica de fallos, sólo se tienen en cuenta los valores de hasta 900 peticiones simultáneas.

Resultados Apache Benchmark

Datos obtenidos

Resultados Apache BenchmarkFallos con peticiones concurrentes

Resultados Apache BenchmarkMedia de tiempo por petición

Resultados Apache BenchmarkMedia de tiempo por petición (media entre concurrentes)

Las conclusiones preliminares

Conclusiones

● Con la nueva configuración (aún en pruebas y sin estar en producción) parece que se aumenta considerablemente el rendimiento y la capacidad de carga soportada, a pesar de tener la mitad de RAM.

● El consumo de RAM con 50.000 peticiones y 1.000 simultáneas es mínimo.

● El servidor sólo deberá servir una petición por página, ya que las imágenes de posts y concursos se sirven desde el CDN de JetPack.

Conclusiones

● Los archivos estáticos css, javascript e imágenes del tema se sirven desde el CDN AWS.

● Otros archivos como las portadas de cada número se sirven desde el CDN de Google App Engine.

● La página servida va comprimida con gzip, con keep-alive y cabeceras de caché en el cliente.

Conclusiones

● Para servir 50.000 peticiones con 500 concurrentes se ha tardado 92,24 segundos (542.06 peticiones por segundo).

● Con esta carga de peticiones se podrían servir más de 32.000 páginas por minuto (los demás archivos, css, js, imágenes, etc. se sirven desde otros servers), casi 2 millones de páginas por hora y más de 46 millones de páginas por día.

Conclusiones

Evidentemente no podemos hacer estos cálculos tan simples y lineales, y ante estas cifras habría

que plantear otros posibles escenarios, ojalá nos viésemos en la necesidad de tener que hacerlo.

Pueden comentar, discutir, rebatir o lo que quieran en

el post donde se ha publicado esta presentación en:

http://www.fotodng.com/pruebas-de-rendimiento-en-

servidor-de-foto-dng-2840.html

Carlos Longarela.

Revista Foto DNG

http://www.fotodng.com

https://twitter.com/fotodng

Agradecimiento especial a

Miguel Ángel de On Services

http://www.onservices.es/