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

Nie będziemy skupiać się na przykładach i testach syntetycznych prowadzących do wniosków, że baza X jest lepsza, bo zapytanie Y działa tam najszybciej, gdyż takie podejście jest mylne. Naszą intencją jest przedstawienie systemów bazodanowych w szerszej perspektywie.

MySQL

Pierwsza wersja tego systemu została wydana 23 maja 1995 roku przez zespół fińskich i szwedzkich programistów.  Została powołana firma MYSQL AB, gdzie rozwijano projekt. Przedsiębiorstwo było jednym z największych przedsięwzięć w sektorze rozwiązań typu open-source na skalę światową. W lutym 2008 roku firma zostaje kupiona przez Sun Microsystems, a w styczniu 2010 roku firma Oracle wykupiła Sun. Przyszłość MySQL wydaje się być niejasna, jednak warto mieć na uwadze projekty poboczne: Drizzle oraz MariaDB.

MySQL obsługuje indeksy typu przestrzennego, widoki, triggery, procedury, tabele w pamięci. Ma replikację na poziomie zapytań i wierszy. Posiada interfejs plugin-ów umożliwiający podłączanie dowolnych funkcjonalności.

Istotną cechą wyróżniającą ten system, jest bogaty wybór tzw. storage engine nawet na poziomie konkretnej tabeli, co pozwala na szczegółowe dostosowanie systemu do konkretnych pożądanych cech środowiska bazodanowego. Poniżej krótka charakterystyka:

Memory:

• Brak transakcji
• Indeksy: Hash, BTree
• Przechowywanie w pamięci RAM
• Buforowanie: nie dotyczy
• Blokady na poziomie tabeli
• Brak kluczy obcych
• Uwagi: zawartość jest ulotna.

MyISAM:

• Brak transakcji
• Indeksy: BTree, RTree, FullText (możliwość spakowania poszczególnych indeksów w celu zmniejszenia zajmowanego miejsca, często prowadzi do przyspieszenia odczytu, ale spowalnia zapis)
• Przechowywanie w plikach (osobno dane, osobno indeksy dla każdej tabeli)
• Buforowanie: cache dla indeksów, dane poprzez cache systemu plików, istnieje możliwość wykorzystania indeksów pokrywających.
• Blokady na poziomie tabeli, ale umożliwia współbieżne dopisywanie nowych rekordów (concurent Insert).
• Brak kluczy obcych
• Uwagi: możliwość spakowania całej tabeli w celu zmniejszenia zajmowanego miejsca (tabela tylko do odczytu).

InnoDB:

• Obsługa transakcji (wiele poziomów izolacji), MVCC, ACID
• Indeksy: BTree + Adaptive Hash Index
• Przechowywanie, dane razem z indeksami, w plikach osobno dla każdej tabeli, wiele tabel w pliku (tzw. tablespace), bezpośrednio na urządzeniu blokowym (także jako table space).
• Buforowanie: ujednolicony bufor stron dla danych, indeksów, metadanych oraz różnych wersji rekordów (MVCC).
• Blokady na poziomie rekordu
• Obsługa kluczy obcych
• Uwagi: Dane i indeksy przechowywane są w postaci B-Drzewa, przez co zawsze musi istnieć klucz główny, jeśli nie jest stworzony jawnie InnoDB automatycznie utworzy ukryty. Pozostałe indeksy nie wskazują bezpośrednio na rekordy danych, ale na indeks główny.

Archive:

• Brak transakcji
• Brak indeksów (Zoptymalizowana pod kątem pełnego skanowania tabeli)
• Przechowywanie: w postaci skompresowanego pliku
• Buforowanie: cache systemu plików
• Blokady na poziomie rekordu
• Brak kluczy obcych
• Uwagi: Umożliwia tylko wykonywanie operacji Insert i Select. Świetnie nadaje się do przechowywania danych statystycznych tam gdzie zwykle/zawsze operuje się na pełnym zbiorze.

CSV:

• Brak transakcji
• Brak indeksów
• Przechowywanie: w postaci pliku CSV
• Buforowanie: cache systemu plików
• Brak blokad
• Brak kluczy obcych
• Uwagi: Umożliwia użycie pliku z danymi w formacie CSV jako tabeli tylko do odczytu (select only) i wykonywanie na danych zapytań w języku SQL.

Merge:

• Uwagi: Mechanizm umożliwiający połączenie kilku tabel MyISAM i traktowanie ich jako jednej. Ma wszystkie cechy MyISAM poza obsługą indeksów pełnotekstowych.

Federated:

• Brak transakcji
• Przechowywanie: zdalny serwer MySQL
• Uwagi: umożliwia użycie tabel przechowywanych na zdalnych serwerach MySQL. Pozostałe cechy zależą od mechanizmu przechowywania tabel na zdalnym serwerze.

NDB (cluster):

• Obsługa transakcji
• Indeksy: Hash, BTree
• Przechowywanie: zdalne i lokalne węzły klastra przechowują dane w RAM i okresowo zrzucają je na dysk
• Buforowanie: pamięć podręczna kluczy i danych
• Blokada na poziomie wiersza
• Brak kluczy obcych
• Uwagi: To bardzo zaawansowane rozwiązanie do specyficznych zastosowań. Obsługuje wewnętrzną synchroniczną replikację z dwufazowym zatwierdzaniem oraz partycjonowanie danych na bazie klucza podstawowego.

Blackhole:

• Uwagi: Ten mechanizm nie przechowuje żadnych danych, jest użyteczny w niektórych scenariuszach replikacji.

Istnieje również stworzony przez firmę Percona ulepszony engine na bazie InnoDB o nazwie XtraDB. Nie różni się on jednak podstawowymi funkcjonalnościami od pierwowzoru. Od wersji 5.1.33 dostępny jest także mechanizm IBMDB2I firmy IBM.

Do obsługi wielu połączeń, wykorzystywany jest mechanizm wątków.

MySQL’a można używać korzystając jednej z licencji: GPL lub komercyjnej.

PostgreSQL

Produkt ten wywodzi się z bazy Ingres ’82, poprzez Postgres (nazwa pochodzi od Post-Ingres) ’89, dalej Postgres95 posiadający język SQL zamiast QUEL, aby ostatecznie nazwać się PostgreSQL dla zaakcentowania zastosowania języka SQL ’96.

System określany jest jako jeden z najbardziej zaawansowanych systemów bazodanowych i ciężko się z tym stwierdzeniem nie zgodzić. Oczywiście oprócz pełnej kompatybilności z ACID, oferuje szereg ogromnie rozbudowanych funkcjonalności:

• Typy danych: oprócz popularnych, możemy operować na danych przestrzennych (spatial), a nawet definiować własne typy danych.
• Indeksy: możliwe są wszelkie kombinacje indeksów częściowych, funkcyjnych, wielokolumnowych czy pełnotekstowych.
• Transakcje: są integralną częścią systemu i pozwalają na zdefiniowanie różnych poziomów izolacji.
• Język proceduralny: mocno rozbudowany PL/pgSQL pozwala na oprogramowanie praktycznie każdej złożonej operacji na danych. Ponadto, możliwe jest tworzenie kodu w innym języku proceduralnym, jak np: PL/Perl czy PL/Python
• Inne: wielce funkcjonalne widoki (views), wyzwalacze (triggers), sekwencje

Jedynie brak spójnego i zintegrowanego systemu wysokiej dostępności, rozłożenia obciążenia i replikacji nie pozwala zaliczyć tego systemu do rozwiązania klasy enterprise. Należy zaznaczyć, iż takie funkcjonalności istnieją, jednak za pośrednictwem rozwiązań zewnętrznych jak np. Slony-II, a natywna replikacja planowana jest na następne wydanie systemu.

Do obsługi wielu połączeń, wykorzystywany jest mechanizm rozwidlania procesów.

PostgreSQL używamy na podstawie własnej licencji tożsamej z licencją BSD czy MIT.

SQLite

System powstał w 2000 roku za sprawą  pracownika General Dynamics na zlecenie US Navy jako projekt mający zastąpić ówczesny system wykorzystywany na niszczycielach rakietowych. Nowy system był projektowany z myślą o braku konieczności skomplikowanej instalacji i zarządzania nim. Ponadto, zrezygnowano z architektury klient-serwer na rzecz biblioteki dołączanej do aplikacji, która dzięki swojemu API operuje na bazie na zasadzie dostępu do lokalnego pliku (podobnie jak np. DBM). W tym miejscu należy zaznaczyć, że baza spełnia warunki określane jako ACID.

Funkcjonalności bazy, jak na rozmiar jej biblioteki, jest bardzo duża: bogaty dialekt SQL, indeksy, transakcje.  Z racji prostej architektury i braku narzutu zdalnej komunikacji, jest również bardzo szybka. Nie nadaje się jednak jako główny system bazodanowy w środowiskach kilku serwerów. Doskonale się natomiast sprawdza w systemach typu embedded (np. Android), czy jako rozwiązania wspomagające (np portage). Niewiele osób ma świadomość,  że  SQLite wykorzystywany jest przez Firefox-a i Thunderbird-a.

Do obsługi wielu połączeń, wykorzystywany jest mechanizm blokady dostępu do lokalnego pliku – bazy danych.

z SQLite korzystamy na podstawie licencji Public Domain

Podsumowanie

Wybór SQLite nad pozostałymi systemami jest dość prosty, gdy mamy bardzo konkretne zastosowanie. Z pozostałymi systemami wybór nie jest już tak oczywisty. Należy wziąć pod uwagę kwestie licencji, jakich funkcjonalności będziemy potrzebowali i z jakim systemem czujemy się najbardziej komfortowo pod względem obsługi. Nie należy natomiast ślepo kierować się opiniami o lepszej wydajności, gdyż te opinie prawie zawsze odnoszą się do konkretnych przypadków – niekoniecznie naszych. Miejmy również na uwadze fakt, iż wymienione projekty są aktywnie rozwijane, zatem lista funkcjonalności dla każdego z nich stale się powiększa.

Geneza:

W roku 1967,  Amerykańska agencja militarna DARPA tworzy/finansuje powstanie sieci rozległej nazwanej ARPANET. Środek okresu zimnej wojny i wielkiej rywalizacji technologicznej USA – ZSRR. Początkowo sieć ma charakter rządowo-militarno-naukowy, po czym w roku 1980 zostaje odseparowana część sieci, którą obecnie nazywamy Internetem. Warto zaznaczyć, iż nawet w czasach obecnych wiele kluczowych dla funkcjonowania sieci elementów działa pod kontrolą DARPA.

Rozwój:

Za rozwój technologii internetowej odpowiada powołana przez DARPA grupa naukowo badawcza IETF, która w obecnych czasach ma charakter nieformalny, otwarty dla każdego i ogólnoświatowy. Celem grupy jest opracowywanie standardów i wytycznych w postaci dokumentów RFC. Oficjalnie zatwierdzone RFC staje się wyznacznikiem dla producentów sprzętu i oprogramowania wykorzystujących sieć Internet.

Adresy IP:

Za adresy IP na samej górze odpowiada organizacja non-profit ICANN (z siedzibą w Kalifornii), a właściwie jej autonomiczna część IANA, której rząd Stanów Zjednoczonych przekazał czasowo prawo nadzoru nad przydziałem adresów IP.  Świat zostaje podzielony na 5 regionów i odpowiadającym im organizacjom drugiego poziomu: AfriNIC (Afryka), APNIC (Azja-Pacyfik), ARIN (Ameryka Północna), LACNIC (Ameryka Południowa, Środkowa i Kariby), oraz RIPE NCC (Europa, Bliski Wschód i Azja Środkowa) z siedzibą w Amsterdamie. Organizacje te bezpośrednio lub co jest częściej spotykane za pośrednictwem dostawców internetu posiadających status LIR (np. TP SA, ATM, GTS), przydzielają adresy IP odbiorcom końcowym.

Odpowiedź na pytanie nie-do-końca pozbawione sensu „kto jest właścicielem internetu”, powinna być teraz łatwiejsza

Trasowanie:

Aby możliwa była komunikacja w Internecie, samo istnienie unikalnych adresów IP nie wystarczy – potrzebny jest jakiś mechanizm przekazujący informacje jak dotrzeć od jednego adresu IP do drugiego. Mechanizmem tym jest protokół routingu (w internecie – BGP), przekazujący informacje pomiędzy urządzeniami zwanymi routerami (w wielkim uproszczeniu np. aby dostać się z adresu A do B, należy przejść przez routery A->X1->X2->X3->B).  Dostawcy internetu tworzą lub podłączają się do różnych punktów wymiany ruchu sobą, zwanych IXP (pomieszczenie techniczne z dużą ilością kabli i routerów).

Warto mieć na uwadze fakt, iż połączenie pomiędzy dwoma punktami (w uproszczeniu adresami IP) w tym samym mieście, może odbywać się przez IXP w bardzo odległej lokacji geograficznej. Pomimo iż nie ma to uzasadnienia technicznego, to takie połączenie może być tańsze dla dostawców internetowych.

Nazwy domenowe:

Dla przeciętnego człowieka, używanie adresów IP w praktyce jest nieakceptowalne: wyobraźmy sobie np zamiast wpisywania http://www.allegro.pl -  http://193.23.48.134/ .  Dlatego właśnie wymyślono domeny i system zamiany adresów domenowych na adresy IP (DNS).  Nazwy domenowe zostały sklasyfikowane na różne poziomy: najwyższy  (np .pl – Polska) i niższe (np edu.pl – edukacyjna,  gov.pl – rządowa, waw.pl – regionalna). Na samej górze serwerów nazw są tzw. root nameservers (w większości znajdują się w Stanach Zjednoczonych), które przechowują między innymi (na obecną chwilę) 248 dwuliterowych domen najwyższego poziomu.

Jako że nie ma przymusu stosowania zaproponowanej klasyfikacji, można sobie zarejestrować domenę np moje.tv co tak naprawdę technicznie jest domeną regionalną wysp Tuvalu .

W Polsce głównym rejestratorem nazw domenowych jest NASK, a inne podmioty działają na mocy porozumienia z NASK.

Filtrowanie/cenzura internetu:

Firmy często decydują się na ograniczanie dostępu do internetu ze względu na swoją politykę bezpieczeństwa. Oprócz blokowania, często zbiera się informacje kto i kiedy przegląda jakie strony itp. O ile przedsiębiorstwo samo decyduje o swojej polityce, to 100% cenzura na skalę krajową jest TECHNICZNIE NIEMOŻLIWA! Istnieje szereg mechanizmów szyfrujących transmisję lub tunelujących połączenia, które skutecznie obejdą wszelkie zabezpieczenia. Z technicznego punktu widzenia, aby skutecznie kontrolować przepływ informacji w Internecie, należałoby odciąć wszystkie połączenia ze światem w Polsce (wliczając np. połączenia satelitarne), co wydaje się również NIEMOŻLIWE!

Możliwe jednak jest wprowadzenie przepisów prawnych np. ograniczających siłę szyfrowania (jak np w USA) i wtedy oczywiście obejście zabezpieczeń będzie technicznie nadal możliwe, jednak obwarowane sankcjami prawnymi.

Przez klaster rozumiemy infrastrukturę, która umożliwia jednoczesne działanie aplikacji z kilku serwerów, przy czym awaria któregokolwiek z nich nie powoduje awarii całej infrastruktury.

Podstawowym warunkiem takiej infrastruktury jest wspólna przestrzeń dyskowa dla każdego serwera. Fakt ten prowadzi do wniosku, że należy oszczędzać operacje wejścia/wyjścia na takiej przestrzeni. Operacje odczytu przeważnie są buforowane i nie wpływają tak znacząco jak operacje zapisu. Należy zatem ograniczyć wszystkie możliwe operacje zapisu do minimum. Tymczasowe pliki być może lepiej przechowywać na lokalnym serwerze klastra, lub jeszcze lepiej na ramdysku serwera. To pozwoli nam na uniknięcie problemu ‘wąskiego gardła’ w obszarze wydajności wspólnej przestrzeni dyskowej.

Pliki sesji można przechowywać na wiele sposobów: na lokalnym systemie plików, w bazie danych, w serwerze cache. Lokalny czy też wspólny system plików odpada ze względu na wydajność. Baza danych jest już lepszym rozwiązaniem, lecz najlepsze efekty uzyskamy stosując serwer cache. Wdrażając to ostatnie, uzyskujemy wspólną usługę do przechowywania sesji, która jest najbardziej wydajna i w dodatku posiada mechanizmy do automatycznego zarządzania przeterminowanymi sesjami.

Dobrą praktyką jest wydzielenie treści statycznej od dynamicznej. To pozwala nam na zastosowanie odrębnych serwerów WWW, przystosowanych do odpowiedniej treści. Mając do dyspozycji skalowalny klaster, możemy spokojnie przerzucić funkcjonalność kompresji dynamicznej zawartości z PHP na odpowiedni serwer WWW, który zrobi to ‘w locie’, a treść statyczna może zostać skompresowana automatycznie i jednorazowo. Użycie kompresji pozwala nam zaoszczędzić na przepustowości internetowej i sprawia, że końcowy użytkownik wyraźnie odczuwa krótsze ładowanie stron i szybszą responsywność na kliknięcia.

Dla uniknięcia przeciążenia serwerów baz danych, stosuje się mechanizm buforowania wyników zapytania, które nie zmieniają się często. Klasyfikacja takich zapytań jest ściśle związana z budową aplikacji. Dodatkowo dla usprawnienia wyszukiwarek zaimplementowanych w aplikacji, stosuje się specjalne serwery indeksacji danych. Zastosowanie tych technologii w odczuwalny sposób poprawiają wydajność baz danych i tym samym aplikacji.

Stosując powyższe praktyki, nasza aplikacja będzie przygotowana na naprawdę duże obciążenie i unikniemy efektu ‘pana gąbki’ z serwisu nasza-klasa.pl

Na rynku dostępny jest szeroki wachlarz usług zapewniających infrastrukturę pod projekty informatyczne. Hosting współdzielony, VPS, RPS, kolokacja własnego serwera, klastry różnego typu. Jakiej infrastruktury potrzebuję? Na co zwrócić uwagę? Poniżej postaramy się odpowiedzieć na te pytania.

Hosting współdzielony jest doskonałą infrastrukturą, jeśli chcemy mieć stronę np. o unikatowych znaczkach wujka, albo o naszym ukochanym kocie Filemonie. Nie mamy zapewnionej żadnej gwarancji oraz redundancji usługi, a na dodatek, jeśli któryś z naszych współ-hostingowych sąsiadów na serwerze zaszaleje z jakimś skryptem PHP (np. postanowi za każdym odwołaniem indeksować cały internet), to cały serwer ma problem – a my z nim. Warto mieć tego świadomość, aby się nie rozczarować.

Serwer wirtualny jest idealnym rozwiązaniem na utrzymywanie serwisów, przy których wolelibyśmy aby nikt inny nie mógł wpłynąć na wydajność naszej infrastruktury. Istnieją firmy, które oferują taką usługę z gwarantowanymi parametrami CPU, RAM i HDD – należy na to zwrócić szczególną uwagę, aby nie mieć problemu jak przy hostingu współdzielonym. Aby mieć pewność co do parametrów, warto przeprowadzić kilka testów, które wykażą faktyczną wydajność. Taka usługa jest również doskonałą platformą startową dla serwisów przy których zależy nam na gwarancji. Ponosimy niskie koszty utrzymania w porównaniu z infrastrukturą bardziej zaawansowaną, a w przypadku sukcesu, można zwiększyć gwarantowaną wydajność.  Nawet jeśli okaże się, że serwis nagle zyskał wysoką popularność, można szybko zwiększyć wydajność poprzez przydzielenie dodatkowej pamięci RAM czy dodatkowe CPU, co daje nam spokój na czas trwania kampanii, a jeśli popularność ciągle rośnie, mamy czas na przesiadkę na odpowiednią infrastrukturę. W konfrontacji z Hostingiem Współdzielonym, tutaj mamy jeszcze tą zaletę, że możemy mieć zainstalowane dowolne oprogramowanie które jest nam potrzebne, oraz konto root (Administratora).

Kolokacja własnego serwera jest w zasadzie na podobnym poziomie jakości jak Serwer Wirtualny, jednak jest rozwiązaniem droższym i trudniejszym w utrzymaniu. Jeśli np. zdarzy się awaria dysku na naszym serwerze – musimy się tym zając, a w przypadku Serwera Wirtualnego – zajmuje się już tym firma hostingowa. Tak samo jest ze zwiększaniem wydajności: jeśli będzie potrzeba dołożenia pamięci, czy wymiana procesora na wydajniejszy/dołożenie kolejnego procesora (o ile istnieją takie możliwości techniczne), musimy się tym zająć.

Rozwiązanie klastrowe jest rozwiązaniem najwyższej klasy jeśli chodzi o infrastrukturę. Posiadamy własne, dedykowane rozwiązanie, a w dodatku odporne na awarię pojedynczego serwera. Istnieją różne rodzaje klastrów pod aplikacje internetowe: od prostych klastrów z 2 serwerów, po potężne systemy w pełni skalowalne. Typ klastra w dużej mierze zależy od naszych oczekiwań co do skalowalności.

Podczas rozważania ofert firm, warto zwrócić uwagę na tzw. usługi dodatkowe, jak np:

• backup (czy automatyczny, jaka retencja danych)
• monitoring (podłączenie do systemu analizowania i powiadamiania w razie awarii usługi lub serwera)
• analiza wydajności (wykresy z pracy różnych obszarów systemu operacyjnego oraz usług – bez tego analiza problemu często przypomina bardziej  zgadywankę)
• zakres prac administratorskich  (czy administrator maksymalnie zrestartuje nam serwer, czy np będzie w stanie analizować problemy i instalować/konfigurować dla nas oprogramowanie

Istotne również jest umiejscowienie centrum danych dla naszej infrastruktury. Zagraniczne oferty kuszą swoją ceną, jednak jakość połączenia internetowego z takimi serwerami często pozostawia wiele do życzenia. Wystarczy sprawdzić czasy odpowiedzi z polecenia ‘ping’ i obejrzeć trasę poleceniem np. ‘mtr’ aby się przekonać. Firmy hostingowe często chwalą się wysoką wydajnością, bezpieczeństwem i fachową opieką. Warto sprawdzić, czy nie są to tylko puste ‘marketingowe’ hasła reklamowe i zapytać co w przypadku np awarii jednego switcha, routera, oraz jak zostałby rozwiązany problem nagłego zapotrzebowania na wydajność przekraczającą możliwości obecnej platformy.

Mamy nadzieję, iż dzięki tej publikacji, wybór infrastruktury stanie się bardziej świadomy.

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.