Jak radzić sobie z ciasteczkami w stosie Varnish

Question

Z powodu powolnego działania strony, zacząłem szukać informacji Varnish jako rozwiązania buforującego i mam kilka pytań na temat Google Analytics.

Jeśli na stronie jest 5 tys. Aktywnych użytkowników (zgodnie z bieżącym raportem ruchu GA), serwer ładuje się na serwerach z backendami do 30-40 +, kolejka startowa pasażera zaczyna się układać i witryna jest prawie bezużyteczna. Zdaję sobie sprawę z powolnych zapytań i pracy z bazami danych, które wymagają lepszej wydajności, ale w tej chwili nie mam zasobów do optymalizacji zapytań i schematu bazy danych, indeksów itp., Więc szukam możliwości dodania lakieru.

stworzyłem schemat aby lepiej wyświetlać stos, oto jak obecny stos wygląda tak: (miejsce obecnie buforuje obrazów/CSS/JS w CDN - Akamai)

ja jak dodać dwie instancje lakieru z przodu serwerów backend do artykułów cache i stos będzie wyglądać następująco:

witryna to serwis informacyjny, a ja patrząc na doradztwo, jak prop skutecznie obsługiwać pliki cookie i buforowanie. W przypadku etapu 1 chciałbym po prostu całkowicie wykluczyć uwierzytelnionych użytkowników i obsługiwać zawartość dynamiczną, ponieważ nie ma wielu jednocześnie uwierzytelnionych użytkowników.

Dezorientacja wynika z plików cookie Google Analytic. Rozumiem, że Google ustawia plik cookie na kliencie za pomocą javascript, a klient komunikuje się bezpośrednio z Google, więc backend nie potrzebuje plików cookie GA wysyłanych przez klienta i można je bezpiecznie usunąć podczas wykonywania podprogramu vcl_recv.

sub vcl_recv { 

// Remove has_js and Google Analytics __* cookies. 
set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_[_a-z]+|has_js)=[^;]*", ""); 
// Remove a ";" prefix, if present. 
set req.http.Cookie = regsub(req.http.Cookie, "^;\s*", ""); 
} 

Pytania

• Czy jest to bezpieczne podejście?
• Czy Google nadal będzie prawidłowo śledzić, w tym powtarzających się użytkowników?
• Czy jest jeszcze coś, o czym należy pamiętać w mojej polityce dotyczącej fazy 1?

Ponieważ domyślnie lakier NIE zapisuje w pamięci podręcznej niczego, co zawiera zestaw ciasteczek, czy można bezpiecznie wdrożyć opisany wyżej stos, dodając zasadę, aby usunąć pliki cookie GA? Rozumiem, że bez dopracowania zasad VCL, nie osiągnę wysokiego współczynnika trafień, jednak podczas moich testów wydaje się, że nawet przy domyślnym lakierze z przodu serwera zaplecza, miał 30% trafień, a po przeanalizowaniu tych, widzę większość z nich to pliki js/css i pliki obrazów, więc niektóre pliki statyczne nie są obsługiwane przez Akamai lub nawet Apache, zamiast tego są przekazywane do Passenger/Rails w celu obsługi statycznego pliku. To zdecydowanie musi zostać poprawione.

• Czy lakierowanie poprawi wydajność z domyślnymi ustawieniami?

Jestem nowy w lakierowaniu, więc wszelkie dodatkowe szczegóły/porady dotyczące lakieru lub stosu, który zaproponowałem, są bardzo doceniane.

Dla fazy 2 +

Ponieważ zawartość aktualizowane, mam zamiar wykonać czystki na obu serwerach lakierniczych, wywołane przez serwery zaplecza, gdy stosuje się odmiany, takie jak komentarzu użytkownika, odsłon, etc .

Istnieje wiele zarchiwizowanych artykułów, które nie są aktualizowane, czy można bezpiecznie przechowywać je w pamięci podręcznej na zawsze?

Ponieważ mam zamiar użyć pamięci RAM do przechowywania lakieru, powinienem mieć dodatkowy (trzeci) lakier i użyć dysku do przechowywania, dla jawnie tych zarchiwizowanych stron. Być może dodanie stosu nginx z przodu serwerów lakierów do kierowania ruchu do konkretnej instancji lakieru dla zarchiwizowanych treści? Load Balancer -> Para odwrotnych serwerów proxy Nginx> Para lakierów -> (lakier LB do 8 serwerów zaplecza)

Doceniam również wszelkie porady dotyczące architektury. Jeśli potrzebujesz więcej informacji, by zapewnić lepszą radę, daj nam znać, a z przyjemnością przedstawimy Ci więcej informacji.

Answer 1

To dużo pytań! :-)

Q. Is this a safe approach? 

Na powierzchni, powiedziałbym tak.

Ogólnie rzecz biorąc, ustawienie Varnish na stronie z wiadomościami, gdzie występuje duży ruch i szybko zmieniająca się zawartość, może być wyzwaniem.

Naprawdę dobry sposób na sprawdzenie jest zbudowanie pojedynczego pola lakieru i daje bezpośredni dostęp do klastra (nie poprzez równoważenia obciążenia) i nadać mu tymczasowy publiczny adres IP. To da ci szansę na przetestowanie zmian VCL. Będziesz mógł testować komentowanie, logować się (jeśli go posiadasz) i cokolwiek innego, aby upewnić się, że nie ma niespodzianek.

Q. Will Google still track properly, including repeat visitors? 

Tak. Pliki cookie są używane tylko po stronie klienta.

Jedną z rzeczy, którą powinieneś obejrzeć, jest to, że gdy serwer pocztowy wysyła plik cookie, Varnish nie będzie również buforować zawartości. Będziesz musiał usunąć wszystkie pliki cookie, które nie są wymagane w vcl_fetch. Może to stanowić problem, jeśli pliki cookie są używane do śledzenia stanu użytkownika.

Będziesz musiał wyłączyć pamięć podręczną stelaża w Railsach i ustawić własne nagłówki. Pamiętaj, że jeśli usuniesz lakier, Railsy będą działały bez buforowania i prawdopodobnie się zwiną!

To co mam w production.rb:

# We do not use Rack::Cache but rely on Varnish instead 
    config.middleware.delete Rack::Cache 
    # varnish does not support etags or conditional gets 
    # to the backend (which is this app) so remove them too 
    config.middleware.delete Rack::ETag 
    config.middleware.delete Rack::ConditionalGet 

I w moim application_controller mam ten prywatny metody:

def set_public_cache_control(duration) 
    if current_user 
    response.headers["Cache-Control"] = "max-age=0, private, must-revalidate" 
    else 
    expires_in duration, :public => true 
    response.headers["Expires"] = CGI.rfc1123_date(Time.now + duration) 
    end 
end 

To się nazywa w moich innych kontrolerów tak, że mam bardzo drobiazgowa kontrola nad tym, jak dużo chacheingu jest stosowane w różnych częściach witryny. Używam metodę konfiguracji w każdym sterownikiem, który jest uruchamiany jako before_filter:

def setup 
    set_public_cache_control 10.minutes 
end 

(application_controller ma filtr i pustą metodę konfiguracji, dzięki czemu może być opcja w pozostałych kontrolerów)

Jeśli część strony, która nie wymaga plików cookie, można usunąć na podstawie adresu URL w VCL i zastosować nagłówki.

Można ustawić czas buforowania dla swoich aktywów statycznych w apache config tak (zakładając używasz domyślną ścieżkę trwałego):

<LocationMatch "^/assets/.*$"> 
    Header unset ETag 
    FileETag None 
    # RFC says only cache for 1 year 
    ExpiresActive On 
    ExpiresDefault "access plus 1 year" 
    Header append Cache-Control "public" 
</LocationMatch> 

<LocationMatch "^/favicon\.(ico|png)$"> 
    Header unset ETag 
    FileETag None 
    ExpiresActive On 
    ExpiresDefault "access plus 1 day" 
    Header append Cache-Control "public" 
</LocationMatch> 

<LocationMatch "^/robots.txt$"> 
    Header unset ETag 
    FileETag None 
    ExpiresActive On 
    ExpiresDefault "access plus 1 hour" 
    Header append Cache-Control "public" 
</LocationMatch> 

nagłówki te będą wysyłane do CDN które buforują aktywa na znacznie dłużej. Podczas oglądania lakieru wciąż pojawiają się żądania przychodzące z malejącą szybkością.

Ustawiłbym również bardzo krótkie buforowanie dla wszystkich treści, w których strony nie wymagają plików cookie, ale często się zmieniają. W moim przypadku ustawiłem czas cache na 10 sekund dla strony głównej. Dla Varnish oznacza to, że jedno żądanie użytkownika trafi do backendu co 10 sekund.

Należy również rozważyć ustawienie lakieru, aby użyć trybu łaski. Pozwala to na wyświetlanie nieco nieaktualnych treści z pamięci podręcznej zamiast wystawiania odwiedzających na powolną odpowiedź z backendu na przedmioty, które właśnie wygasły.

Q. There are plenty of archived articles that don't get updated, is it safe to cache them forever? 

Aby to zrobić, musisz zmienić aplikację, aby wysyłać różne nagłówki artykułów zarchiwizowanych. Zakłada się, że nie będą miały plików cookie. W oparciu o to, co robię na moim miejscu, zrobiłbym to w ten sposób: -

w konfiguracji powyżej dodać warunkowego, aby zmienić czas cache:

def setup 
    # check if it is old. This code could be anything 
    if news.last_updated_at < 1.months.ago 
    set_public_cache_control 1.year 
    else 
    set_public_cache_control 10.minutes 
    end 
end 

Ustawia publiczny nagłówek, więc lakier będzie buforuj go (jeśli nie ma plików cookie), tak samo jak wszelkie zdalne pamięci podręczne (w ISP lub firmowych bramach).

Problem polega na tym, że chcesz usunąć historię lub zaktualizować ją (powiedzmy, z powodów prawnych).

W takim przypadku należy przesłać Varnish prywatny nagłówek, aby zmienić TTL dla tego adresu URL, ale wysłać krótszy publiczny nagłówek dla wszystkich pozostałych.

Pozwoliłoby to ustawić Varnish, aby wyświetlać treści przez (powiedzmy) 1 rok, podczas gdy wysyła nagłówki, aby poinformować klientów, że będą wracać co 10 minut.

W tych przypadkach konieczne jest dodanie reżimu do usuwania lakieru.

aby zacząć mam drugą metodę w moim application_controller:

def set_private_cache_control(duration=5.seconds) 
    # logged in users never have cached content so no TTL allowed 
    if ! current_user 
    # This header MUST be a string or the app will crash 
    if duration 
     response.headers["X-Varnish-TTL"] = duration.to_s 
    end 
    end 
end 

iw moim vcl_fetch mam to:

call set_varnish_ttl_from_header; 

i funkcji VCL to:

sub set_varnish_ttl_from_header { 
    if (beresp.http.X-Varnish-TTL) { 
    C{ 
     char *x_end = 0; 
     const char *x_hdr_val = VRT_GetHdr(sp, HDR_BERESP, "\016X-Varnish-TTL:"); /* "\016" is length of header plus colon in octal */ 
     if (x_hdr_val) { 
     long x_cache_ttl = strtol(x_hdr_val, &x_end, 0); 
     if (ERANGE != errno && x_end != x_hdr_val && x_cache_ttl >= 0 && x_cache_ttl < INT_MAX) { 
      VRT_l_beresp_ttl(sp, (x_cache_ttl * 1)); 
     } 
     } 
    }C 
    remove beresp.http.X-Varnish-TTL; 
    } 
} 

Oznacza to, że nagłówek NIE jest przekazywany (co robi s-max-age) do jakichkolwiek pamięci podręcznych.

Sposób konfiguracja może wyglądać następująco:

def setup 
    # check if it is old. This code could be anything 
    if news.last_updated_at < 1.months.ago 
    set_public_cache_control 10.minutes 
    set_private_cache_control 1.year 
    else 
    set_public_cache_control 10.minutes 
    end 
end 

Zapraszam do zadawania dodatkowych pytań, a ja zaktualizować tę odpowiedź!