Mam system działający pod kontrolą nginx / php-fpm / varnish / wordpress i amazon s3.

Teraz podczas konfigurowania systemu przejrzałem wiele plików konfiguracyjnych i we wszystkich znalazłem coś takiego:

    /* If the request is for pictures, javascript, css, etc */
    if (req.url ~ "\.(jpg|jpeg|png|gif|css|js)$") {
        /* Remove the cookie and make the request static */
        unset req.http.cookie;
        return (lookup);
    }

Nie rozumiem, dlaczego tak się dzieje. Większość przykładów uruchamia także NginX jako serwer WWW. Teraz pytanie brzmi: dlaczego miałbyś używać pamięci podręcznej lakieru do buforowania tych plików statycznych.

Dla mnie bardziej sensowne jest buforowanie tylko plików dynamicznych, aby php-fpm / mysql nie został trafiony tak bardzo.

Czy mam rację, czy coś mi brakuje?

AKTUALIZACJA

Chcę dodać informacje do pytania na podstawie udzielonej odpowiedzi.

Jeśli masz dynamiczną witrynę internetową, w której treść bardzo się zmienia, chaching nie ma sensu. Ale jeśli używasz WordPress na przykład na statycznej stronie internetowej, może to być buforowane przez długi czas.

To powiedziawszy, dla mnie ważniejsza jest statyczna zgodność . Znalazłem link z niektórymi testami i testami porównawczymi w różnych aplikacjach pamięci podręcznej i aplikacjach serwera WWW.

http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/

NginX jest w rzeczywistości szybszy w uzyskiwaniu zawartości statycznej, więc sensowniej jest po prostu pozwolić jej przejść. NginX działa świetnie z plikami statycznymi.

-

Poza tym przez większość czasu zawartość statyczna nie znajduje się nawet w samym serwerze internetowym. Przez większość czasu ta zawartość jest przechowywana gdzieś w CDN, może AWS S3, coś w tym rodzaju. Myślę, że pamięć podręczna lakieru to ostatnie miejsce, w którym chcesz przechowywać zawartość statyczną.

Lakier ma kilka zalet. Pierwszym, który zauważysz, jest zmniejszenie obciążenia serwera zaplecza. Zwykle przez buforowanie treści, która jest generowana dynamicznie, ale zmienia się rzadko (w porównaniu do częstotliwości dostępu). Biorąc przykład z Wordpress, większość stron prawdopodobnie nie zmienia się bardzo często, a istnieją pewne wtyczki, które unieważniają pamięć podręczną lakieru podczas zmiany strony (tj. Nowy post, edycja, komentarz itp.). Dlatego buforujesz w nieskończoność i unieważniasz przy zmianie - co powoduje minimalne obciążenie serwera backend.

W załączonym artykule, pomimo braku zgody, większość ludzi sugeruje, że Varnish działa lepiej niż Nginx, jeśli jest poprawnie skonfigurowany - chociaż (i naprawdę nie chcę tego przyznać) - moje własne testy wydają się zgadzać, że nginx może obsłużyć plik statyczny szybciej niż lakier ( na szczęście nie używam do tego celu lakieru). Myślę, że problem polega na tym, że jeśli w końcu użyjesz Lakieru, do konfiguracji dodałeś dodatkową warstwę. Przeniesienie tej dodatkowej warstwy do serwera zaplecza zawsze będzie wolniejsze niż tylko podawanie bezpośrednio z zaplecza - i dlatego zezwolenie Varnishowi na buforowanie może być szybsze - oszczędzasz krok. Inną zaletą jest przód dysku-io. Jeśli skonfigurujesz lakier do korzystania z malloc, wcale nie trafisz na dysk, co pozostawia go dostępnym dla innych procesów (i zwykle przyspieszałby).

Uważam, że potrzebny byłby lepszy punkt odniesienia, aby naprawdę zmierzyć wydajność. Wielokrotne żądanie tego samego pojedynczego pliku wyzwala pamięć podręczną systemu plików, która zaczyna odwracać uwagę od samych serwerów sieciowych. Lepszym testem porównawczym byłoby użycie oblężenia z kilkoma tysiącami losowych plików statycznych (prawdopodobnie nawet z dzienników serwera) w celu symulacji realistycznego ruchu. Prawdopodobnie jednak, jak wspomniałeś, coraz bardziej powszechne jest przenoszenie zawartości statycznej do CDN, co oznacza, że ​​Varnish prawdopodobnie nie będzie jej obsługiwał (wspominasz S3).

W scenariuszu w świecie rzeczywistym priorytetem byłoby wykorzystanie pamięci - najpierw zawartość dynamiczna, ponieważ jest ona najdroższa do wygenerowania; następnie mała zawartość statyczna (np. js / css), a na koniec obrazy - prawdopodobnie nie buforowałbyś innych mediów w pamięci, chyba że masz naprawdę dobry powód, aby to zrobić. W tym przypadku, gdy Varnish ładuje pliki z pamięci, a nginx ładuje je z dysku, Varnish prawdopodobnie przewyższy nginx (pamiętaj, że pamięci podręczne nginx służą tylko do proxy i fastCGI, a te domyślnie są oparte na dysku - chociaż jest to możliwe użycie nginx z memcached).

(Mój szybki - bardzo szorstki, nie dający żadnej wiarygodności - test wykazał, że nginx (bezpośredni) był najszybszy - nazwijmy go 100%, lakier (z malloc) był nieco wolniejszy (około 150%), a nginx za lakierem ( z pass) był najwolniejszy (około 250%). To mówi samo za siebie - wszystko albo nic - dodając dodatkowy czas (i przetwarzanie) na komunikację z backendem, po prostu sugeruje, że jeśli używasz Lakieru i masz pamięć RAM do oszczędzenia , równie dobrze możesz po prostu buforować wszystko, co możesz i podawać z Varnish zamiast wracać do nginx.)

Myślę, że możesz coś przegapić.

Z definicji zmieniają się pliki dynamiczne. Zazwyczaj zmieniają się, wykonując zapytanie do bazy danych, które wpływa na treść strony obsługiwanej przez użytkownika. Dlatego nie chcesz buforować zawartości dynamicznej. Jeśli to zrobisz, staje się po prostu treścią statyczną i najprawdopodobniej treścią statyczną o niepoprawnej treści.

Jako prosty przykład załóżmy, że masz stronę z zalogowaną nazwą użytkownika na górze strony. Za każdym razem, gdy strona jest ładowana, uruchamiane jest zapytanie do bazy danych w celu ustalenia, która nazwa użytkownika należy do zalogowanego użytkownika żądającego strony, co zapewnia wyświetlenie właściwej nazwy. Jeśli buforujesz tę stronę, zapytanie do bazy danych nie zostanie wykonane, a wszyscy użytkownicy zobaczą tę samą nazwę użytkownika u góry strony i prawdopodobnie nie będzie to ich nazwa użytkownika. Musisz wykonać to zapytanie przy każdym ładowaniu strony, aby upewnić się, że dla każdego użytkownika wyświetlana jest poprawna nazwa użytkownika. Dlatego nie jest buforowalny.

Rozszerz tę logikę na coś bardziej problematycznego, np. Uprawnienia użytkownika, a zobaczysz, dlaczego dynamiczna zawartość nie powinna być buforowana. Jeśli baza danych nie zostanie trafiona z powodu zawartości dynamicznej, CMS nie ma możliwości ustalenia, czy użytkownik żądający strony ma uprawnienia do przeglądania tej strony.

Treść statyczna jest z definicji taka sama dla wszystkich użytkowników. Dlatego nie trzeba przeprowadzać zapytań do bazy danych, aby dostosować tę stronę dla każdego użytkownika, więc warto buforować, aby wyeliminować niepotrzebne zapytania do bazy danych. Obrazy to naprawdę świetny przykład zawartości statycznej - chcesz, aby wszyscy użytkownicy widzieli ten sam obraz nagłówka, te same przyciski logowania itp., Więc są doskonałymi kandydatami do buforowania.

W powyższym fragmencie kodu widać bardzo typowy fragment VCL programu Varnish, który wymusza buforowanie obrazów, css i javascript. Domyślnie Varnish nie buforuje żadnego żądania zawierającego plik cookie. Logika polega na tym, że jeśli w żądaniu znajduje się plik cookie, musi istnieć jakiś powód, dla którego serwer potrzebuje tego pliku cookie, więc jest on wymagany na zapleczu i musi zostać przekazany przez pamięć podręczną. W rzeczywistości wiele CMSów (Drupal, Wordpress itp.) Dołącza pliki cookie do prawie wszystkiego, niezależnie od tego, czy jest to potrzebne, więc często pisze się VCL, aby usunąć pliki cookie z treści, o których wiadomo, że są statyczne, co z kolei powoduje buforowanie lakieru to.

Ma sens?

W przypadku treści dynamicznych niektóre notowania giełdowe faktycznie zmieniają się często (aktualizowane co sekundę SaaS serverod a backend server), ale mogą być wyszukiwane jeszcze częściej (dziesiątki tysięcy subscription clients):

[stock calculation / backend server] ----- [SaaS server] ------ [subscription clients]

W tym przypadku, buforowanie na SaaS serveraktualizacji na sekundę od backend serversumożliwia zaspokojenie zapytań o dziesiątkach tysięcy subscription users.

Bez pamięci podręcznej na serwerze SaaS ten model po prostu nie działałby.

Buforowanie plików statycznych za pomocą Varnish byłoby korzystne pod względem odciążenia Nginx. Oczywiście, jeśli masz dużo plików statycznych do buforowania, marnuje pamięć RAM. Jednak Varnish ma fajną funkcję - obsługuje wiele backendów pamięci dla swojej pamięci podręcznej.

Dla plików statycznych: pamięć podręczna na HDD Wszystko inne: pamięć podręczna na RAM.

To powinno dać ci lepszy wgląd w sposób wdrażania tego scenariusza: http://www.getpagespeed.com/server-setup/varnish-static-files-cache