pruebas servidor revista foto dng
Post on 10-May-2015
176 Views
Preview:
DESCRIPTION
TRANSCRIPT
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/
top related