Czym jest revProxy?

Serwer revProxy znajduje się pomiędzy jednym lub kilkoma serwerami WWW a klientem przeglądającym stronę. Żądania wyświetlenia strony trafiają najpierw do revProxy, który (o ile już nie posiada ważnej kopii) pobiera element z serwera WWW (jak np. strona HTML, obrazek czy CSS) i zapisuje go w swojej pamięci.  Jeśli pojawia się żądanie o ten sam element, do klienta zostaje wysłana kopia zamiast oryginalnego elementu z serwera WWW. Główną zaletą takiego scenariusza jest zmniejszenie obciążenia na serwerach WWW, a tym samym szybsze ładowanie stron.

Czy revProxy jest rozwiązaniem dla mnie?

Opisywana technologia jest niestety mało popularna, a szkoda.  Poza koniecznością zaznajomienia się z mechanizmami sterującymi działaniem revProxy, występuje obawa, że straci się informacje na temat statystyk serwisu. W praktyce jednak, sterowanie revProxy jest proste, a statystyki można generować na podstawie np. kodu JavaScript zamiast logu serwera WWW.

Istnieje również niebezpieczeństwo, że w przypadku awarii serwera revProxy, strona przestanie się wyświetlać. Przy zastosowaniu odpowiednich rozwiązań load-balancer, infrastruktura może być odporna na taką awarię i w przypadku problemów z funkcjonowaniem revProxy,  cały ruch automatycznie zostanie przekierowany bezpośrednio na serwery WWW, lub na inny serwer revProxy.

Ekonomiczna zaleta tej technologii jest dość oczywista. Zmniejszenie obciążenia serwerów WWW, oznacza mniejszą ilość serwerów WWW, co prowadzi do mniejszych kosztów utrzymania.

Jak działa procedura korzystania z cache w revProxy?

W dużym uproszczeniu, wymieniamy poniżej kilka głównych zasad, którymi należy się kierować:

• Jeśli nagłówki odpowiedzi HTTP zawierają instrukcje aby nie cache-ować obiektu, nie będzie on cache-owany.
• Jeśli obiekt jest autoryzowany, bądź bezpieczny (HTTPS), nie będzie cache-owany.
• Obiektu w cache jest uznawany za świeży, jeśli posiada informacje o okresie świeżości i ten okres nie minął.
• Jeśli obiekt nie jest uznany za świeży,  revProxy odwoła się do serwera WWW i pobierze nową wersję obiektu, lub oznaczy obiekt jako niezmieniony i nadal świeży.

W przypadku, gdy obiekt nie zawiera informacji o walidacji (nagłówek ETag lub Last-Modified) oraz nie posiada dokładnego określenia co do swojego okresu ważności, w większości przypadków taki obiekt zostanie uznany za nie cache-owalny. Określenie świeżości obiektu oraz informacji o jego walidacji stanowią podstawę przy wdrażaniu revProxy do serwisu WWW.

Jak sterować revProxy z poziomu serwisu WWW?

• Meta tag w HTML

Informacje zawarte w treści obiektu HTTP z pewnością nie wpłyną na działanie revProxy, ponieważ tylko nagłówki są brane pod uwagę. Meta tagi mogą być przydatne do kontroli cache w przeglądarce, ale to też nie we wszystkich przeglądarkach. Nie należy stosować tej metody do sterowania działaniem revProxy

• Nagłówek odpowiedzi ‘Pragma’ dla HTTP 1.0
  

W sieci można znaleźć porady, aby stosować nagłówek HTTP ‘Pragma: no-cache’, aby zabezpieczyć obiekt przed cache-owaniem.  Ta metoda kontroli nad cache była stosowana za czasów protokołu HTTP 1.0 . Można oczywiście używać tego nagłówka jako dodatkowego, ale dobrze administrowany serwer revProxy będzie używał protokołu HTTP 1.1 i ten nagłówek będzie zbędny, oraz może prowadzić do problemów w przypadku rozbieżności w ustawieniach pozostałych nagłówków. Nie zalecamy stosowania nagłówków Pragma.

• Nagłówek odpowiedzi ‘Expires’ dla HTTP 1.0
  

Nagłówek ten wysłany z serwera WWW jest jednym ze sposobów na sterowaniem walidacją obiektów w revProxy. Przykład nagłówka:

Expires: Fri, 30 Oct 2011 14:19:41 GMT

Jak widać, nagłówek przyjmuje wartość daty (koniecznie w formacie GMT), zatem idealnie nadaje się do ustalenia ważności obiektu jako konkretny moment w czasie. Ponieważ nagłówek pochodzi z czasów HTTP 1.0, nie zalecamy stosowania tego nagłówka.

• Nagłówek odpowiedzi ‘Cache-Control’ dla HTTP 1.1
  

Od momentu pojawienia się standardu HTTP 1.1, pojawiła się o wiele bardziej elastyczna metoda na kontrolę revProxy, w postaci tego nagłówka. Przykład:

Cache-Control: max-age=3600, must-revalidate

Poniżej kilka przydatnych opcji wartości nagłówka:

• max-age=(sekundy). Określa maksymalną ilość czasu, dla którego dany obiekt będzie świeży. Funkcjonalność podobna do nagłówka ‘Expires’, z tą jednak różnicą, że tu podajemy ilość sekund a nie moment w czasie.
• s-max-age=(sekundy). Opcja podobna do max-age, jednak odnosi się wyłącznie do wspólnych (shared) cache, jak np revProxy, ale już nie do prywatnych (private) jak np. cache przeglądarki konkretnego użytkownika.
• public. Użycie tej opcji informuje revProxy o tym, że może cache-ować dany obiekt, nawet jeśli klient został zautoryzowany. Jeśli np. mamy do czynienia ze stroną, do której należy się zalogować, revProxy standardowo nie zachowa tej strony. Przy użyciu tej opcji, revProxy zachowa taką stronę w cache.
• private. Ta opcja powoduje, iż obiekt jest przeznaczony wyłącznie dla danego użytkownika i będzie mógł zostać zapisany w cache przeglądarki danego użytkownika, natomiast nie może on zostać zapamiętany w revProxy i dostępny dla wszystkich.
• no-cache. Użycie tej opcji powoduje wymuszenie w revProxy sprawdzenia obiektu na serwerze revProxy, za każdym razem. Jeśli obiekt przechodzi walidację (pobrany z serwera WWW jest taki sam jak w cache), to klient otrzymuje kopię bez pobierania z revProxy, a w przeciwnym razie obiekt zostanie w całości pobrany z serwera WWW.
• no-store. Ta opcja wyłącza całkowicie jakiekolwiek przechowywanie obiektu w cache i powoduje za każdym razem pobranie obiektu od serwera WWW przez revProxy do klienta.
• must-revalidate. Dzięki tej opcji, można wymusić, aby obiekt który stracił ważność, bezwzględnie został odświeżony z serwera WWW. Serwer revProxy może w szczególnych przypadkach przesłać obiekt, który stracił ważność (np w przypadku problemu ze skontaktowaniem się z serwerem WWW).

Zbiór wszystkich nagłówków i opcji jest określony w dokumencie RFC na temat specyfikacji protokołu HTTP 1.1

• Nagłówek odpowiedzi ‘Vary’ dla HTTP 1.1
  

Nagłówek ten jest wymagany do poprawnego funkcjonowania mechanizmów revProxy. Określa on inne nagłówki, których wartości stanowią kryteria dla wyboru wersji obiektu. Minimalną wartością dla nagłówka ‘Vary’ jest : Accept-Encoding, aby rozróżnić wersję obiektu, który jest np. skompresowany i nie skompresowany. Nie należy podawać nadmiernej ilości nagłówków, ponieważ prowadzi to do przeciążenia revProxy identycznymi obiektami w wielu instancjach (np. ten sam obrazek, ale przechowywany w cache dla każdej wartości nagłówka User-Agent).

• Walidacja obiektów

Proces, podczas którego revProxy sprawdza, czy obiekt w jego cache jest taki sam jak na serwerze WWW, nazywa się właśnie walidacją. Jeśli walidacja się powiedzie, revProxy nie musi pobierać całego obiektu od serwera WWW. Zapewnienie możliwości walidacji jest niezmiernie ważnym elementem podczas dostosowywania serwisu WWW do możliwości skorzystania z revProxy. Popularnym walidatorem jest nagłówek odpowiedzi HTTP ‘Last-Modified’.  Podobnie jak ‘Expires’, określa moment w czasie, gdy obiekt został zmodyfikowany. Jeśli data ‘Last-Modified’ jest późniejsza niż data w której obiekt został pobrany z serwera WWW, obiekt nie przechodzi walidacji i jest pobierany w całości ze źródłowego serwera WWW.

Protokół HTTP 1.1 zdefiniował nowy nagłówek odpowiedzi – ‘ETag’. Wartość tego nagłówka jest identyfikatorem jednoznacznie określającym wersję obiektu (zawartość obiektu, czas modyfikacji, etc).

Jak sprawdzić nagłówki z mojej strony WWW?

Doskonałym serwisem, który umożliwia sprawdzenie nagłówki oraz ich interpretację jest REDbot.org.

Powodzenia przy dostosowywaniu swojej strony WWW

Moja definicja tego parametru to: Średnia ilość procesów w kolejce do wykonania w okresie, odpowiednio 1, 5 i 15 minut. Innymi słowy, jest to miara obciążenia systemu procesami. Anglojęzyczni czytelnicy mogą również przeczytać definicję na wikipedii.

Jak wiadomo, Unix jest systemem wielozadaniowym, czyli np. jest w stanie niby ‘jednocześnie’ wykonywać kilka procesów. Jeśli tych procesów mamy kilka, to trafiają one do odpowiedniej kolejki (we FreeBSD nazywa się ona runnable) i stamtąd mechanizm zarządzania dostępem do zasobów (sheduler), decyduje który proces ma otrzymać czas procesora, a który ma czekać. Ilość procesów w tej kolejce mierzona jako średnia, w trzech wspomnianych okresach, jest właśnie wartością Load Average.

A co się dzieje w przypadku, gdy np. mamy kilka procesów, które chcą działać jednocześnie? To mi przypomina moje pytanie ‘pomocnicze’ zadane jednemu z kandydatów:

• Ile procesów może działać jednocześnie na jednym procesorze, i do tego (jakby to miało jakiekolwiek znaczenie) 64 bitowym?
• (chwila zastanowienia i pada odpowiedź) 1024!
• Taaak? A dlaczego?
• A nie, … (znów chwila zastanowienia): 4096!
• Ok, przejdźmy do następnego pytania…

Oczywiście nie da się na jednym procesorze (1 rdzeń, bez obsługi wielowątkowości i zakładamy że jest to ”zwykły’ procesor dla jasności) wykonywać jednocześnie kilku procesów. W danej chwili może działać co najwyżej jeden proces, a reszta czeka na swoją kolej.

Warto zdać sobie sprawę z faktu, że to, że proces istnieje w systemie, nie musi koniecznie oznaczać że ma on dostęp do zasobów (CPU). Weźmy np. uruchomiony proces serwera apache, wraz z procesami potomnymi. Jeśli nikt z niego nie korzysta, po prostu sobie jest, ale nic nie robi poza oczekiwaniem na żądania. Przykładowe procesy serwera nie znajdują się więc w kolejce do wykonania.

No dobrze, to teraz jaka wartość Load Averago to dużo? To oczywiście zależy ile mamy procesorów. Jeśli mamy 2 CPU a każdy po 4 rdzenie, to mamy w sumie tych rdzeni 8. W takim przypadku jeśli parametr LA dochodzi do wartości 8, to jest to wartość graniczna po której procesy nie będą działać optymalnie, ponieważ w danym przedziale czasu jest więcej procesów oczekujących na wykonanie niż dostępnych procesorów. Skutkiem tego będzie odbieranie dostępu do procesorów obecnie działającym procesom i przekazanie tego dostępu innym znajdującym się w kolejce do wykonania. Tak naprawdę, to trzeba jeszcze odliczyć trochę mocy na pracę samego systemu.

Na koniec ciekawostka: W Linuxie sprawa wygląda trochę inaczej niż we FreeBSD, a mianowicie proces który czeka na dane z podsystemu I/O też jest wliczany do  LA.  Z punktu widzenia procesu w Linuxie jest tak, że to przecież nie jego, tylko sytemu, wina że potrzebne do działania dane nie znajdują się jeszcze w pamięci i że gdyby nie to, to on już dawno jest gotowy do wykonania. Możemy zatem zaobserwować zjawisko, gdy procesor(y) będą nieobciążone, za to dyski będą skrzeczeć jak szalone i LA będzie wynosić 100, 200 a nawet więcej.