Wydajność Nginx Fastcgi_cache - buforowany bufor VS tmpfs buforowany plik statyczny VS

Question

Dwa ostrzeżenia: ta wydajność uzależnia. Każdy kawałek, który wyciskasz, chcesz więcej. A angielski to mój drugi język, więc wybaczcie mi błędy.

W każdym razie porównuję wydajność nginx dla stron z wordpress w różnych scenariuszach i coś wydaje się dziwne. Więc jestem tutaj, aby podzielić się z wami i być może dostosować moje oczekiwania.

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 

To jest mała instancja ec2. Wszystkie testy wykonywane przy użyciu jednoczesnych żądań SIEGE 40 przez 2 minuty. Wszystkie testy wykonane z localhost> localhost.

Scenariusz jeden - adres URL buforowane przez fastcgi_cache do tmpfs (pamięć)
oblężenie C40 -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 

Scenariusz dwa - samej zawartości pamięci podręcznej na dysku poprzez fastcgi_cache (EC2 oninstance danych - ulotne)

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 

Tu fi pierwsze pytanie pojawia się. Nie widzę ogromnej różnicy na ramie na dysku. Czy to normalne? Mam na myśli, nie ma ogromnych korzyści z używania pamięci podręcznej RAM.

Scenariusz trzy - na tej samej stronie, zapisane jako .html a serwerem przez 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 

Oto główne pytanie. To ogromna różnica. Chodzi mi o to, że obsługa AFAIK z bufora ma być równie szybka, jak serwowanie statycznego pliku .html, prawda? Mam na myśli - nginx widzi, że istnieje reguła pamięci podręcznej dla lokalizacji i widzi, że istnieje wersja z pamięci podręcznej, obsługuje ją. Dlaczego tak wiele różnic?

Cache działa poprawnie

35449 - 
    10835 HIT 
    1156 MISS 
    1074 BYPASS 
    100 EXPIRED 

pozdrawiam.

Answer 1

Oto krótkie podsumowanie dochodzenia w nginx listy (patrz the thread here):

Przede wszystkim, numery podane są bardzo niskie. Powinny być znacznie większe, a odpowiedź na oryginalne pytanie ("dlaczego różnica") nie ma sensu. Prawidłowe pytanie brzmi "dlaczego tak wolno". Nawet mała instancja EC2 powinna działać lepiej.

Podczas dochodzenia stwierdzono, że host jest związany z procesorem, a filtr gzip i moduł pagepeed są najbardziej głodne procesora.

Podstawowe zalecenia:

1. Zastosowanie gzip_static plików statycznych. Pozwala to na obsługę skompresowanej wersji i oszczędzanie CPU w czasie wykonywania.
2. Unikaj wysokich poziomów kompresji gzip (gzip_comp_level). Wysoki poziom kompresji wymaga o wiele więcej procesora niż domyślny (1), a różnica wielkości jest niewielka.
3. Spróbuj wyłączyć wysyłanie stron, aby sprawdzić, czy to pomaga.

Z gzip off; pagespeed off; zgłoszono 30x przyspieszenie.