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ą.
źródło
if (req.url ~ "\.(png|gif|jp(e?)g|avi|flv|mp(e?)g|mp4|mp3)"){return(pass);}w vcl_recv (). Zasadniczo nie chcę buforować multimediów - ale zdecydowanie chcę buforować html (php), a nawet js / css (teoria mówi, że obrazy mają mniejszy udział w postrzeganym czasie ładowania strony niż układ).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?
źródło
W przypadku treści dynamicznych niektóre notowania giełdowe faktycznie zmieniają się często (aktualizowane co sekundę
SaaS serverod abackend server), ale mogą być wyszukiwane jeszcze częściej (dziesiątki tysięcysubscription clients):W tym przypadku, buforowanie na
SaaS serveraktualizacji na sekundę odbackend serversumożliwia zaspokojenie zapytań o dziesiątkach tysięcysubscription users.Bez pamięci podręcznej na serwerze SaaS ten model po prostu nie działałby.
źródło
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
źródło