2013-10-03 15 views
5

Due avvertenze: questa prestazione è avvincente. Ogni cosa spremuta, vuoi di più. E l'inglese è la mia seconda lingua, quindi scusami per eventuali errori.Prestazioni Nginx Fastcgi_cache - Disco memorizzato nella cache VS tmpfs memorizzato nella cache VS file statico

In ogni caso sto confrontando le prestazioni di nginx per i siti web di wordpress in diversi scenari e qualcosa sembra strano. Quindi sono qui per condividere con voi ragazzi e forse modificare le mie aspettative.

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 

Questa è una piccola istanza di ec2. Tutti i test eseguiti utilizzando richieste simultanee di SIEGE 40 per 2 minuti. Tutti i test eseguiti da localhost> localhost.

Scenario uno - Un URL cache tramite fastcgi_cache a tmpfs (MEMORY)
SIEGE -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 

Scenario due - stesso URL memorizzato nella cache tramite fastcgi_cache su disco (EC2 stoccaggio oninstance - effimera)

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 

Qui è dove la fi la prima domanda appare. Non vedo un'enorme differenza su ram su disco. È normale? Voglio dire, nessun vantaggio enorme sull'utilizzo della cache ram.

Scenario tre - La stessa pagina, salvato come html e server 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 

Ecco la domanda principale. Questa è un'enorme differenza. Voglio dire, AFAIK che serve dalla cache dovrebbe essere veloce quanto servire un file .html statico, giusto? Voglio dire - nginx vede che c'è una regola di cache per la posizione e vede che c'è una versione cache, serve. Perché tanta differenza?

Cache sta lavorando bene

35449 - 
    10835 HIT 
    1156 MISS 
    1074 BYPASS 
    100 EXPIRED 

i migliori saluti.

risposta

7

Ecco breve riassunto di ricerca in mailing list nginx (vedi the thread here):

Prima di tutto, i numeri riportati sono molto bassi. Dovrebbero essere molto più grandi e rispondere alla domanda originale ("perché la differenza") non ha molto senso. La domanda corretta sarebbe "perché così lento". Anche una piccola istanza di ec2 dovrebbe fare meglio.

Durante lo svolgimento dell'indagine, l'host è stato trovato vincolato dalla CPU, con il filtro gzip e il modulo di velocità della pagina che ha più fame di CPU.

raccomandazioni di base sono:

  1. Usa gzip_static per i file statici. Permette di servire una versione precompressa e salva la CPU in fase di runtime.
  2. Evitare l'uso di livelli di compressione gzip elevati (gzip_comp_level). Livelli di compressione elevati richiedono molta più CPU rispetto al valore predefinito (1), mentre la differenza di dimensioni è ridotta.
  3. Provare a spegnere la velocità della pagina per vedere se aiuta.

Con gzip off; pagespeed off; 30x aumento di velocità è stato segnalato.

+0

Maxim mi ha aiutato a risolvere questo problema sulla mailing list di nginx. Risulta il mio gzip al volo stava mangiando tutta la cpu. Mi ha indicato la giusta direzione con gzip_static. QUINDI ricorda i ragazzi se vuoi prendere molti utenti di sim non usare un livello di alto livello gzip a meno che tu non abbia la CPU da risparmiare. I risparmi non ne valgono la pena. Se fai pre-gzip e usi gzip static fai attenzione ai timestamp dei file gzip e non gzip deve avere lo stesso timestamp, questo è il modo migliore per andare. – ddutra

+1

@ddutra quindi, dopo aver seguito questi consigli, quali sono stati i risultati dei test? Hanno concepito risultati significativi? – Zhianc

+0

@ddutra qualsiasi informazione mi aiuterà –

Problemi correlati