Jak prawidłowo ustawić lakier do witryn Symfony2?

Question

Mam stronę internetową (z ESI), która używa odwrotnego proxy Symfony2 do buforowania. Średnia odpowiedź wynosi około 100ms. Próbowałem zainstalować Varnish na serwerze, aby go wypróbować. Poszłam za krokiem guide from Symfony cookbook, usunąłem wszystko w folderze cache, ale folder http_cache wciąż był tworzony, gdy go wypróbowałem. Pomyślałem więc, że mógłbym wypróbować komentarz $kernel = new AppCache($kernel); z app.php. To działało całkiem dobrze. http_cache nie został stworzony już i przez varnishstat, Lakier wydawało się działać:

12951   0.00   0.08 cache_hitpass - Cache hits for pass 
1153   0.00   0.01 cache_miss - Cache misses 

To było z około 14.000 wniosków, więc pomyślałem, że wszystko będzie w porządku. Ale po echolowaniu dowiedziałem się, że odpowiedzi wzrosły do ​​~ 2 sekund.

Apache działa na porcie 9000 i Lakieru na 8080. Więc echo używałem echoping -n 10 -h http://servername/ X.X.X.X:8080.

Nie mam pojęcia, co może być nie tak. Czy są jakieś dodatkowe ustawienia potrzebne do użycia Varnish z Symfony2? Czy po prostu robię coś nie tak?

---

Na życzenie, oto mój default.vcl z modyfikacjami, które dotychczas zrobiłem.

znalazłem 2 problemy z lakierem w domyślnej konfiguracji:

• to nie wnioski cache z cookies (i wszyscy w mojej aplikacji jest sesja przydzielony)
• ignoruje Cache-Control: no-cache nagłówka

Więc dodałem warunki dla tych przypadków do mojej konfiguracji i działa całkiem dobrze teraz (~ 175 req/s z ~ 160 z odwrotnym proxy S2 - ale szczerze, spodziewałem się trochę więcej). Po prostu nie mam pojęcia, jak sprawdzić, czy wszystko jest w porządku, więc wszelkie dane wejściowe są mile widziane.

Większość stron ma pamięć podręczną zróżnicowaną według plików cookie, z s-maxage 1200. Typowe pliki ESI nie są urozmaicone przez pliki cookie, z s-maxage dość nisko (artykuły, listy artykułów). Strony profilów użytkowników nie są w ogóle buforowane (no-cache) i nie jestem do końca pewien, czy ESI zawiera je nawet w pamięci podręcznej Varnish. Tylko ESI, które są zmieniane za pomocą plików cookie, jest nagłówkiem z informacjami specyficznymi dla użytkownika (na 100% stron).

Wszystko w tym poście jest lakierem 3.X specyficznym (osobiście używam wersji 3.0.2).

Również po kilku tygodniach wkopywania się w to, nie mam pojęcia, co robię, więc jeśli znajdziesz coś dziwnego w konfiguracjach, po prostu daj mi znać.

Answer 1

Jeśli to całą swoją konfiguracji vcl_recv jest skonfigurowany dwukrotnie.

Na stronach, które chcesz buforować, możesz wysłać nagłówki buforowania? Byłoby to najrozsądniejsze, ponieważ obrazy prawdopodobnie mają już nagłówki buforowania apache, a logika aplikacji decyduje o stronach, które mogą być faktycznie buforowane, ale można to również wymusić w lakierze.

Można użyć vcl_recv tak:

# Called after a document has been successfully retrieved from the backend. 
sub vcl_fetch { 

    # set minimum timeouts to auto-discard stored objects 
    # set beresp.prefetch = -30s; 
    set beresp.grace = 120s; 

    if (beresp.ttl < 48h) { 
     set beresp.ttl = 48h;} 

    if (!beresp.cacheable) 
     {pass;} 

    if (beresp.http.Set-Cookie) 
     {pass;} 

    # if (beresp.http.Cache-Control ~ "(private|no-cache|no-store)") 
    # {pass;} 

    if (req.http.Authorization && !beresp.http.Cache-Control ~ "public") 
     {pass;} 

} 

tej jednej pamięci podręcznej, w lakier, tylko wnioski, które są ustawione buforowalny. Pamiętaj też, że twoja konfiguracja nie buforuje żądań za pomocą plików cookie.

Answer 2

Jestem zaskoczony, że nie miał naprawdę pełnej odpowiedzi w ciągu 10 miesięcy. To może być naprawdę przydatna strona.

Ty sobie podkreślić, że:

• Lakier nie wnioski cache ciasteczek
• Lakier ignoruje Cache-Control: no-cache nagłówek

Pierwszą rzeczą jest to, czy wszyscy w twojej aplikacji potrzebujesz sesji? Jeśli nie, nie rozpoczynaj sesji, a przynajmniej nie opóźniaj jej uruchamiania, dopóki nie będzie to naprawdę konieczne (np. Zalogowanie się lub cokolwiek innego).

Jeśli nadal możesz zapisywać strony w pamięci podręcznej po zalogowaniu się użytkowników, musisz być naprawdę ostrożny, nie wyświetlając użytkownikowi strony przeznaczonej dla kogoś innego. Ale jeśli masz zamiar to zrobić, edytuj vcl_recv(), aby usunąć plik cookie sesji dla stron, które chcesz buforować.

Możesz łatwo uzyskać Varnish, aby przetworzyć dyrektywę bez użycia cache w vcl_fetch() i faktycznie już to zrobiłeś.

Innym problemem, który znalazłem jest to, że Symfony przez domyślne zestawy max-age do 0, co oznacza, że ​​nie będą one nigdy się buforowane przez domyślnej logiki w vcl_fetch

Zauważyłem również, że miałeś zestaw portów w Lakierze do:

backend default { 
    .host = "127.0.0.1"; 
    .port = "80"; 
} 

Sam powiedziałeś, że Apache działa na porcie 9000, więc to nie pasuje. Normalnie ustawisz Varnish, aby nasłuchiwał na domyślnym porcie (80) i ustawisz Varnish, aby wyszukać backend na porcie 9000 lub cokolwiek innego.