blog.sher.pl

Wszystkie posty otagowane skalowalność

Właśnie skończyłem oglądać świetną prezentację prelegenta z soccerway.com, jednej z największych stron na świecie serwujących wyniki sportowe w czasie niemal rzeczywistym.

Opowiada on publice na Spodku 2.0 jak powinno się pisać skalowalne aplikacje, opisuje infrastrukturę ich ogromnego serwisu i wyjawia sztuczki, dzięki którym obsługują 15 000 żądań na sekundę. Worth seeing.

Tagi: skalowalność

Co pod Facebook piszczy? Dowiesz się z tej strony. Najpopularniejszy serwis społecznościowy zdradził co kryje się za jego infrastrukturą, jakie narzędzia używają jego programiści i w jakich projektach biorą udział. Wspaniała okazja by popracować nad skalowalnością swojej witryny.

Co pod Facebook piszczy? Dowiesz się z tej strony. Najpopularniejszy serwis społecznościowy zdradził co kryje się za jego infrastrukturą, jakie narzędzia używają jego programiści i w jakich projektach biorą udział.

Wspaniała okazja by popracować nad skalowalnością swojej witryny.

Z pewnością znasz pojęcie relacyjnej bazy danych, używana jest na co dzień przez większość deweloperów (zwykle jest to MySQL). Istnieje jednak inny typ bazy danych. Nie ma ona tabeli, kolumn ani schematów. Wszystkie informacje zapisane są w postaci kluczy i przypisanych im wartości. Redis jest uważany przez wielu programistów za najlepszą bazę typu klucz-wartość. Zapytasz czy taki sposób przechowywania danych ma sens. Otóż ma. Relacyjne bazy danych są trudne w skalowaniu. Rozdzielenie naszego serwisu na więcej niż jedną maszynę wymaga wielu skomplikowanych zabiegów. W przypadku Redis nie ma najmniejszego problemu dołożyć choćby tysiąc nowych maszyn.

Z pewnością znasz pojęcie relacyjnej bazy danych, używana jest na co dzień przez większość deweloperów (zwykle jest to MySQL). Istnieje jednak inny typ bazy danych. Nie ma ona tabeli, kolumn ani schematów. Wszystkie informacje zapisane są w postaci kluczy i przypisanych im wartości. Redis jest uważany przez wielu programistów za najlepszą bazę typu klucz-wartość.

Zapytasz czy taki sposób przechowywania danych ma sens. Otóż ma. Relacyjne bazy danych są trudne w skalowaniu. Rozdzielenie naszego serwisu na więcej niż jedną maszynę wymaga wielu skomplikowanych zabiegów. W przypadku Redis nie ma najmniejszego problemu dołożyć choćby tysiąc nowych maszyn.

Yam.pl, klon Twittera, nowy konkurent Blipa, Flakera czy Pingera oparty jest na otwartym silniku status.net (tak, możesz za darmo stworzyć swój serwis mikroblogowy). Ale nie o tym mowa. Chcę wskazać ciekawy wzorzec, mianowicie przycisk “Masz x nowych wiadomości”. Po kliknięciu ładowane są pInne rozwiązania to oczywiście nie wyświetlanie nowych wpisów, wymuszenie ręcznego odświeżenia ciągłe pobieranie i wstawianie pełnych wpisów przez AJAX Rozwiązanie status.net ma jednak kilka niepodważalnych zalet dla serwisów, które chcą obsługowiwać duży ruch: Użytkownik jest powiadamiany o nowych wpisach. Kontrprzykładem jest Flaker, gdzie użytkownicy z niecierpliwości odświeżają stronę, pomimo braku nowych wpisów. Pożera to ogromne ilości transferu. Ponieważ pobierane są same nowe wpisy, które objętościowo stanowią procent całego dokumentu, oszczędzamy znowu na transferze. Całe wpisy pobierane są jedynie w przypadku kliknięcia przycisku - w czasie rzeczywistym jest pobierana jedynie liczba nieprzeczytanych wiadomości - zmniejszamy czas żądania, obciążenie bazy danych i znowu transfer - przesyłane jest jedynie paro-bajtowa liczba. Takie rozwiązanie można jeszcze bardziej zoptymalizować. Zamiast stosować odpytywanie serwera co parę sekund żądaniami AJAX, można użyć modelu COMET (push). W skrócie: to nie przeglądarka odpytuje serwer czy są nowe wiadomości, lecz serwer powiadamia o tym przeglądarkę. Istnieją dwie metody przesyłania informacji z serwera do przeglądarki. Pierwsza opiera się na tradycyjnych zapytaniach AJAX, których jednak serwer nie zamyka, dopóty dopuki nie zechce odesłać jakiejś informacji. Druga metoda (najbardziej optymalna) pozbawiona jest wszelkich (możliwych) strat na transferze: przesyłana jest jedynie istotna informacja, bez opakowania jej w nagłówki HTTP. Mowa tu o WebSockets czyli wynalazku HTML5. Niestety WebSockets nie są  obsługiwane przez wszystkie obecne przeglądarki, więc realne rozwiązania muszą być hybrydowe. Jeśli chciałbyś poznać szerzej tematykę powiadamiania Push, polecam zapoznać się z silnikami APE oraz NodeJS. Ciekawostką jest, że korzystają one z JavaScript po stronie serwera.

Yam.pl, klon Twittera, nowy konkurent Blipa, Flakera czy Pingera oparty jest na otwartym silniku status.net (tak, możesz za darmo stworzyć swój serwis mikroblogowy). Ale nie o tym mowa.

Chcę wskazać ciekawy wzorzec, mianowicie przycisk “Masz x nowych wiadomości”. Po kliknięciu ładowane są pInne rozwiązania to oczywiście

  1. nie wyświetlanie nowych wpisów, wymuszenie ręcznego odświeżenia
  2. ciągłe pobieranie i wstawianie pełnych wpisów przez AJAX

Rozwiązanie status.net ma jednak kilka niepodważalnych zalet dla serwisów, które chcą obsługowiwać duży ruch:

  1. Użytkownik jest powiadamiany o nowych wpisach. Kontrprzykładem jest Flaker, gdzie użytkownicy z niecierpliwości odświeżają stronę, pomimo braku nowych wpisów. Pożera to ogromne ilości transferu.
  2. Ponieważ pobierane są same nowe wpisy, które objętościowo stanowią procent całego dokumentu, oszczędzamy znowu na transferze.
  3. Całe wpisy pobierane są jedynie w przypadku kliknięcia przycisku - w czasie rzeczywistym jest pobierana jedynie liczba nieprzeczytanych wiadomości - zmniejszamy czas żądania, obciążenie bazy danych i znowu transfer - przesyłane jest jedynie paro-bajtowa liczba.

Takie rozwiązanie można jeszcze bardziej zoptymalizować. Zamiast stosować odpytywanie serwera co parę sekund żądaniami AJAX, można użyć modelu COMET (push). W skrócie: to nie przeglądarka odpytuje serwer czy są nowe wiadomości, lecz serwer powiadamia o tym przeglądarkę.

Istnieją dwie metody przesyłania informacji z serwera do przeglądarki. Pierwsza opiera się na tradycyjnych zapytaniach AJAX, których jednak serwer nie zamyka, dopóty dopuki nie zechce odesłać jakiejś informacji.

Druga metoda (najbardziej optymalna) pozbawiona jest wszelkich (możliwych) strat na transferze: przesyłana jest jedynie istotna informacja, bez opakowania jej w nagłówki HTTP. Mowa tu o WebSockets czyli wynalazku HTML5.

Niestety WebSockets nie są  obsługiwane przez wszystkie obecne przeglądarki, więc realne rozwiązania muszą być hybrydowe.

Jeśli chciałbyś poznać szerzej tematykę powiadamiania Push, polecam zapoznać się z silnikami APE oraz NodeJS. Ciekawostką jest, że korzystają one z JavaScript po stronie serwera.