Rendimiento de Nginx Fastcgi_cache: disco en caché VS tmpfs en caché VS archivo estático

3 minutos de lectura

Dos advertencias: esto del rendimiento es adictivo. Cada vez que aprietas, quieres más. Y el inglés es mi segundo idioma, así que perdónenme por cualquier error.

De todos modos, estoy comparando el rendimiento de nginx para sitios web de wordpress en diferentes escenarios y algo parece extraño. Así que estoy aquí para compartir con ustedes y tal vez ajustar mis expectativas.

Software                                                                            
#       NGINX 1.4.2-1~dotdeb.1                                                          
#       PHP5-CGI 5.4.20-1~dotdeb.1                                                      
#       PHP-FPM 5.4.20-1~dotdeb.1                                                       
#       MYSQL Server 5.5.31+dfsg-0+wheezy1                                              
#       MYSQL Tuner 1.2.0-1                                                             
#       APC opcode 3.1.13-1 

Esta es una pequeña instancia ec2. Todas las pruebas realizadas con SIEGE 40 solicitudes simultáneas durante 2 minutos. Todas las pruebas realizadas desde localhost > localhost.

Escenario uno: una URL almacenada en caché a través de fastcgi_cache en TMPFS (MEMORIA)

ASEDIO -c 40 -b -t120s ‘http://www.joaodedeus.com.br/quero-visitar/abadiania-go

Transactions:                    1403 hits
Availability:                 100.00 %
Elapsed time:                 119.46 secs
Data transferred:              14.80 MB
Response time:                  3.36 secs
Transaction rate:              11.74 trans/sec
Throughput:                     0.12 MB/sec
Concurrency:                   39.42
Successful transactions:        1403
Failed transactions:               0
Longest transaction:            4.43
Shortest transaction:           1.38

Escenario dos: la misma URL almacenada en caché a través de fastcgi_cache en el disco (almacenamiento en instancia ec2 – efímero)

Transactions:                    1407 hits
Availability:                 100.00 %
Elapsed time:                 119.13 secs
Data transferred:              14.84 MB
Response time:                  3.33 secs
Transaction rate:              11.81 trans/sec
Throughput:                     0.12 MB/sec
Concurrency:                   39.34
Successful transactions:        1407
Failed transactions:               0
Longest transaction:            4.40
Shortest transaction:           0.88

Aquí es donde aparece la primera pregunta. No veo una gran diferencia entre la memoria RAM y el disco. ¿Eso es normal? Quiero decir, no hay un gran beneficio en el uso de memoria RAM.

Escenario tres: la misma página, guardada como .html y servidor por nginx

Transactions:                    1799 hits
Availability:                 100.00 %
Elapsed time:                 120.00 secs
Data transferred:              25.33 MB
Response time:                  2.65 secs
Transaction rate:              14.99 trans/sec
Throughput:                     0.21 MB/sec
Concurrency:                   39.66
Successful transactions:        1799
Failed transactions:               0
Longest transaction:            5.21
Shortest transaction:           1.30

Aquí está la pregunta principal. Esta es una gran diferencia. Quiero decir, AFAIK se supone que servir desde el caché es tan rápido como servir un archivo .html estático, ¿verdad? Quiero decir: nginx ve que hay una regla de caché para la ubicación y ve que hay una versión en caché, la sirve. ¿Por qué tanta diferencia?

El caché funciona bien

    35449 -
  10835 HIT
   1156 MISS
   1074 BYPASS
    100 EXPIRED

Saludos.

Aquí hay un breve resumen de la investigación en la lista de correo de nginx (ver el hilo aquí):

En primer lugar, los números reportados son muy bajos. Deberían ser mucho más grandes, y responder a la pregunta original (“por qué la diferencia”) realmente no tiene sentido. La pregunta correcta sería “por qué tan lento”. Incluso una pequeña instancia ec2 debería funcionar mejor.

Durante la investigación, se descubrió que el host estaba vinculado a la CPU, y que el filtro gzip y el módulo de velocidad de página eran los que más CPU consumían.

Las recomendaciones básicas son:

  1. Usar gzip_static para archivos estáticos. Permite servir una versión precomprimida y ahorra CPU en tiempo de ejecución.
  2. Evite usar niveles altos de compresión gzip (gzip_comp_level). Los altos niveles de compresión requieren mucha más CPU que la predeterminada (1), mientras que la diferencia de tamaño es pequeña.
  3. Intente desactivar la velocidad de la página para ver si ayuda.

Con gzip off; pagespeed off; Se informó una aceleración de 30x.

  • Maxim me ayudó a resolver esto en la lista de correo de nginx. Resulta que mi gzipping sobre la marcha estaba consumiendo toda la CPU. Me indicó la dirección correcta con gzip_static. Así que recuerden, muchachos, si quieren tomar muchos usuarios de sim, no usen un nivel alto de comp gzip a menos que tengan CPU de sobra. Los ahorros no valen la pena. Si hace pre-gzip y usa gzip static, preste atención a las marcas de tiempo del archivo gzip y no gzip tiene que tener la misma marca de tiempo, esta es la mejor manera de hacerlo.

    – ddutra

    04/10/2013 a las 18:31


  • @ddutra luego de seguir estos consejos, ¿cuáles fueron los resultados de sus pruebas? ¿Concibieron resultados significativos?

    -Zhianc

    22 de noviembre de 2014 a las 12:13

  • @ddutra cualquier información me ayudará

    – Bar Amir

    9 de noviembre de 2015 a las 3:01

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad