Duże aplikacje i load balancing, Czyli co i jak zrobic jak maszyna nie daje rady |
Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.
Duże aplikacje i load balancing, Czyli co i jak zrobic jak maszyna nie daje rady |
2.08.2008, 18:53:14
Post
#1
|
|
Admin Techniczny Grupa: Administratorzy Postów: 2 071 Pomógł: 93 Dołączył: 5.07.2005 Skąd: Olsztyn |
Temat założony na prośbę SHIPa oraz normanosa traktujący o rozkładaniu obciążenia na wiele maszyn
|
|
|
2.08.2008, 19:01:00
Post
#2
|
|
Grupa: Zarejestrowani Postów: 1 415 Pomógł: 117 Dołączył: 7.09.2005 Skąd: Warszawa Ostrzeżenie: (0%) |
Muskający powierzchnię tematu wpis na blogu Talena z serii "Duże portale".
|
|
|
4.08.2008, 20:33:26
Post
#3
|
|
Grupa: Zarejestrowani Postów: 10 Pomógł: 1 Dołączył: 18.07.2007 Ostrzeżenie: (0%) |
dzięki za link do mojego bloga, widzę, że temat ostatnio robi się coraz popularny :-)
kiedy ten temat rusza ? sam mam wkrótce zacząć pracę nad (miejmy nadzieje) dużym portalem - chętnie porównam swoje opinie i nauczę się czegoś nowego... |
|
|
5.08.2008, 11:02:55
Post
#4
|
|
Grupa: Zarejestrowani Postów: 461 Pomógł: 32 Dołączył: 17.09.2003 Skąd: Łódź Ostrzeżenie: (0%) |
No to Panowie zaczynajmy - może na początek odnosząc się do tego co kolega (jeśli nie masz nic przeciwko takiemu zwracaniu się) wrauk napisał na swoim blogu. Problem sesji - jak byście proponowali go rozwiązać tak by nie utracić wydajności ani nie musieć rezygnować z funkcjonalności sesji. Oczywiście zakładam tutaj sytuację posiadania x serwerów www i możliwość trafienia requestów do dowolnych z nich w szczególności możliwość trafienia dwóch różnych requestów do dwóch różnych serwerów.
Przyznam się szczerze, że nie mam jeszcze pomysłu jak to rozwiązać. Może koledzy mają jakiś pomysł ? Pozdrawiam, Łukasz ps: jaki przyjemny temat pokrywający się trochę z tematem mojej magisterki |
|
|
5.08.2008, 12:25:49
Post
#5
|
|
Grupa: Zarejestrowani Postów: 535 Pomógł: 27 Dołączył: 3.05.2005 Ostrzeżenie: (20%) |
A jest możliwość utworzenia dysku sieciowego i na nim trzymania sesji tak że każdy serwer będzie miał do niego dostęp ?
|
|
|
5.08.2008, 12:37:12
Post
#6
|
|
Grupa: Zarejestrowani Postów: 461 Pomógł: 32 Dołączył: 17.09.2003 Skąd: Łódź Ostrzeżenie: (0%) |
Pomysł dość dobry ale wydaje mi się, że problemem będzie tutaj użycie semaforów by ograniczyć możliwość jednoczesnego dostępu do danych sesyjnych. Tak by dwa skrypty na raz z nimi nie grzebały.
Oczywiście można zrobić tak, że w sesji przechowujemy tylko informacje: - zalogowany: tak/nie - identyfikator użytkownika - jakieś dane użytkownika co się rzadko zmieniają a pokazujemy jest na stronie - adres ip (chyba, że mechanizm handlera sesji posiada zabezpieczenie przed zmianą ip) Ja bym to zrobił tak, że robię dedykowaną maszynę sesyjną, która ma coś na wzór bazy danych - przechowuje sesje, łączysz się z nią poprzez socketa i odpytujesz. Tyle, że w tym wypadku: - trzeba napisać soft do tej maszyny, który będzie bardzo szybki, będzie świetnie cacheował i kolejkował dane, będzie potrafił zadbać o bezpieczeństwo - napisać moduł do php'a za pomocą którego będzie się do tego odwoływało (można oczywiście ręcznie sockety otwierać ale myślę, że moduł byłby lepszy), w szczególności moduł mógłby być non stop odpalony i mieć stałe połączenie z serwerem sesyjnym by nie tracić na wydajności. To taki pomysł na szybko ale na ile opłacalny to nie wiem ... na pewno sporo czasu by poszło na oprogramowanie tego i czy zyski wynikające z wydajności zrekompensowałyby straty czasu poświęconego na oprogramowanie tego. I pytanie czy nie ma prostszego rozwiązania, które także się spisze i może będzie trochę mniej wydajne ale w ostatecznym rachunku wyjdzie lepiej ? Ten pomysł z dyskiem sieciowym byłby nawet dość dobry - tyle, że dysk musiałby być wpięty w architekturę o dużej przepustowości i sam najpewniej być RAID'em na SAS'ach. Do tego pozostaje problem rozwiązania konkurencyjności. pozdr. Łukasz |
|
|
5.08.2008, 12:55:10
Post
#7
|
|
Grupa: Zarejestrowani Postów: 10 Pomógł: 1 Dołączył: 18.07.2007 Ostrzeżenie: (0%) |
Soft do obsługiwania takich sesji już istnieje i nazywa się mcache - pisałem o nim na blogu.
Co do ilości danych przechowywanych w sesji, to zawsze musi to być kompromis pomiędzy tym ile można zapisać, aby maksymalnie odciążyć bazę i utrzymać sesje na zadowalającym poziomie. Można się np.: zastanowić nad zapamiętywaniem części danych w sesji, a dopiero garbage collector zapisywał by dane do bazy. Na szczęście sesjami bardzo dobrze się balansuje i rozwiązanie oparte o bazę danych może być bardzo wydajne. Wystarczy wziąć dwie pierwsze litery z hasha i obliczyć modulo z liczy dostępnych serwerów. Dzięki temu zapytanie o sesję zawsze trafi do konkretnego serwera - zawsze tego samego. Skalowalność takiego rozwiązania rozbije się dopiero o maksymalną liczbę jednoczesnych połączeń, ale to można tylko załatwić przez kierowanie danego użytkownika do tego samego serwera www (lub tej samej grupy serwerów), np.: na podstawie adresu IP. |
|
|
5.08.2008, 13:41:27
Post
#8
|
|
Grupa: Zarejestrowani Postów: 793 Pomógł: 32 Dołączył: 23.11.2006 Skąd: Warszawa Ostrzeżenie: (0%) |
Można się np.: zastanowić nad zapamiętywaniem części danych w sesji, a dopiero garbage collector zapisywał by dane do bazy. Ten akurat pomysł jest niezbyt dobry moim zdaniem, zapis danych powinien być natychmiastowy, co innego gromadzenie informacji w sesji, zamiast pobierania z bazy. Jak na tym forum jest np. nick i id, tylko kłopot pojawia się jak te dane mogą się zmienić, ale to da się też zrobić. Chyba było o tym coś na blogu technicznym Grona, odnoście buforowania wygenerowanych stron (co prawda przykłady były w Python). -------------------- Algorytmy w PHP, czy ktoś o tym słyszał?
Dlaczego tak mało kobiet programuje? ponieważ nie zajmują się głupotami. |
|
|
5.08.2008, 21:09:04
Post
#9
|
|
Grupa: Zarejestrowani Postów: 535 Pomógł: 27 Dołączył: 3.05.2005 Ostrzeżenie: (20%) |
Cytat Pomysł dość dobry ale wydaje mi się, że problemem będzie tutaj użycie semaforów by ograniczyć możliwość jednoczesnego dostępu do danych sesyjnych. Tak by dwa skrypty na raz z nimi nie grzebały. Przecież jeden user to jedna sesja tym samym jeden user może się znajdować na jednym serwerze i tylko ten jeden serwer może te dane modyfikować czyż nie tak ? |
|
|
5.08.2008, 21:18:30
Post
#10
|
|
Grupa: Przyjaciele php.pl Postów: 7 494 Pomógł: 302 Dołączył: 31.03.2004 Ostrzeżenie: (0%) |
Przecież jeden user to jedna sesja tym samym jeden user może się znajdować na jednym serwerze i tylko ten jeden serwer może te dane modyfikować czyż nie tak ? No właśnie nie.Podczas jednego żądania użytkownik może zostać obsłużony przez jeden serwera a podczas kolejnego przez drugi, przecież pomiędzy żądaniami (w obrębie jednej sesji) obciążenie serwerów może się zmienić. |
|
|
5.08.2008, 21:22:56
Post
#11
|
|
Grupa: Zarejestrowani Postów: 10 Pomógł: 1 Dołączył: 18.07.2007 Ostrzeżenie: (0%) |
Przecież jeden user to jedna sesja tym samym jeden user może się znajdować na jednym serwerze i tylko ten jeden serwer może te dane modyfikować czyż nie tak ? Nie nie nie, nic bardziej błędnego. Żyjemy w czasach w których "praca z ajaxem jest czystym relaxem" i witryna która jego nie wykrozystuje nie jest trendy (trendy jest już passe, teraz edgy jest trendy). W każdym razie nigdy nie można założyć, że tylko jeden skrypt pracuje na sesji. I dla tego też warto robić session_close zaraz po pobraniu danych z sesji (o ile nie ma potrzeby modyfikacji danych sesji), bo standardowo (sesja na plikach) PHP zwalnia sesję dopiero po wykonaniu skryptu, co powoduje, że zapytania ajax'owe wykonywane teoretycznie równolegle tak naprawdę są wykonywane szeregowo (do dodatkowo rzutuje na większe obciążenie serwera przez połączenia które 'wiszą' i czekają w kolejce). |
|
|
5.08.2008, 22:08:59
Post
#12
|
|
Grupa: Zarejestrowani Postów: 149 Pomógł: 12 Dołączył: 3.03.2008 Skąd: łódzkie Ostrzeżenie: (0%) |
Witam, specjalnie doświadczony nie jestem, ale tak myśląc nad tym problemem wyszło mi co nie co, nie wiem, może to głupie, ale może ktoś lepsiejszy i bardziej doświadczony podchwyci myśl, albo spojrzy na problem podobnie do mnie.
Otóż, przy pierwszym wejściu na stronę jest to nie ważne na jaki serwer trafimy, i z reguły trafiamy na najmniej obciążony zgodnie z algorytmem loadbalancingu. Następne wejścia jednak powinny już trafić do tego pierwszego serwera. Skoro serwery się zmieniają losowo to jedynym sposobem na zachowanie informacji który serwer był pierwszy jest... ciastko na maszynie klienta z jakimś id, po którym aplikacja na każdym z serwerów rozpozna ten pierwszy serwer i na niego przekieruje żądanie? Mankament to userzy nie akceptujący ciastek, ale wtedy może jakaś zmienna doklejana do url'a ? Decyzje o przekierowaniu podejmuje najmniej obciążony serwer, więc OK. Podobne to chyba do rozwiązań z wspólną DB, gdzie była by tabela z polem w którym jest hash z jakichś stałych parametrów klienta (IP, przeglądarka, OS, ?) i znowu aplikacja na samym wstępie zawsze musiała by sprawdzać czy taki hash już istnieje i jeśli tak to odczytać serwer dla niego i tam przekierować. Pytanie tylko czy takie sprawdzania i przekierowania same w sobie nie są już wystarczająco wolne ? No i w sumie to nie wiem jak miała by wyglądać implementacja takiego przekierowania w PHP (tutaj się objawia mój brak doświadczenia) :/ Bo tak, jak mamy żądanie, jakiś URL, trafiamy z nim do aplikacji na jakiś serwer. Wykonuje się skrypt PHP i jak z tego skryptu PHP przekierować... pod ten sam URL na inną maszynę tylko (DNSy, IP, wykorzystanie exec()?) Może na zasadzie, że każdy z tych kilku serwerów ma swoją subdomenę skonfigurowaną tak samo jak jedna główna domena i wtedy aplikacja przekierowywała by za pomocą subdomen, a żądanie jak już by trafiło na serwer to za pomocą mod_rewrite było by przepisywane na główną domenę? No nic, tak czy siak według mnie najlepszym miejscem na przechowanie informacji co do pierwszego serwera jest klient (bądź jego stałe dane), bo to klient jest stały, a serwery się zmieniają. -------------------- "Jeden człowiek nie zmieni świata, ale jeden człowiek może przekazać informację która zmieni świat." - David Icke
| PAMIĘTAJ, JESTEŚ POLAKIEM !!! | Jam jest Polska, Ojczyzna Twoja, ziemia Ojców, z której wzrosłeś. Wszystko, czym jesteś, po Bogu - mnie zawdzięczasz!! |
|
|
6.08.2008, 07:56:52
Post
#13
|
|
Grupa: Zarejestrowani Postów: 10 Pomógł: 1 Dołączył: 18.07.2007 Ostrzeżenie: (0%) |
Otóż, przy pierwszym wejściu na stronę jest to nie ważne na jaki serwer trafimy, i z reguły trafiamy na najmniej obciążony zgodnie z algorytmem loadbalancingu. Następne wejścia jednak powinny już trafić do tego pierwszego serwera. Zaawansowane load balancery za dużo $$$ mają takie możliwości. Skoro serwery się zmieniają losowo to jedynym sposobem na zachowanie informacji który serwer był pierwszy jest... ciastko na maszynie klienta z jakimś id, po którym aplikacja na każdym z serwerów rozpozna ten pierwszy serwer i na niego przekieruje żądanie? Mankament to userzy nie akceptujący ciastek, ale wtedy może jakaś zmienna doklejana do url'a ? .... Wydaje mi się, że podstawowe założenie jest błędne, bo zakładasz, że każdy request dotrze do PHP, co nie jest prawdą. Podstawą zmiejszania obciążenia serwerów jest cache i duże wartości dla nagłówków Expires. No i, tak jak wspomniałeś, pojawia się duży problem z ruchem wewnętrznym (bo przekierowanie header-location powoduje, że znowu pakiety przejdą przez load balancer, co może oznaczać, że potrzebujemy 100 requestów, żeby trafić na właściwy serwer :-) ). |
|
|
6.08.2008, 08:51:23
Post
#14
|
|
Grupa: Zarejestrowani Postów: 149 Pomógł: 12 Dołączył: 3.03.2008 Skąd: łódzkie Ostrzeżenie: (0%) |
Zaawansowane load balancery za dużo $ mają takie możliwości. Tak, wczoraj przed snem wziąłem się za lekturę Twoich wpisów na blogu, dobrnołem do części 3 i zaraz jadę dalej Żałuję, że udzieliłem się w tym wątku przed przeczytaniem Wydaje mi się, że podstawowe założenie jest błędne, bo zakładasz, że każdy request dotrze do PHP, co nie jest prawdą. Podstawą zmiejszania obciążenia serwerów jest cache i duże wartości dla nagłówków Expires. No i, tak jak wspomniałeś, pojawia się duży problem z ruchem wewnętrznym (bo przekierowanie header-location powoduje, że znowu pakiety przejdą przez load balancer, co może oznaczać, że potrzebujemy 100 requestów, żeby trafić na właściwy serwer :-) ). Innymi requestami jak PHPowe to chyba nie trzeba się tak przejmować ? Wszak request o statyczny zasób, grafikę nie uruchamia całej logiki PHP dającej narzut parsera PHP i z reguły narzut łączenia się z bazą i mielenia przez nią. Nie mniej oczywiście, że skoro są narzędzia to lepiej je wykorzystać i tak chyba w jednym z Twoich wpisów jest link do podstawowej konfiguracji mod_cache Apacha, ciekawe to ciekawe. A jeśli chodzi o ruch wewnętrzny to napisałem, że header-locatiowanie miało by operować na subdomenach, które były by unikalne dla każdego z serwerów, a mod_rewrite docelowego serwera spowrotem przepisywał by na główną domenę. A więc load balancer musiał by reagować tylko przy requeście z główną domeną, a requesty subdomenowe wymuszone przez przekierowanie header-location powinny już trafiać zgodnie z adresem, bez load balancowania. Ale z racji swojego małego doświadczenia nie wiem czy tak się da i może głupoty piszę -------------------- "Jeden człowiek nie zmieni świata, ale jeden człowiek może przekazać informację która zmieni świat." - David Icke
| PAMIĘTAJ, JESTEŚ POLAKIEM !!! | Jam jest Polska, Ojczyzna Twoja, ziemia Ojców, z której wzrosłeś. Wszystko, czym jesteś, po Bogu - mnie zawdzięczasz!! |
|
|
6.08.2008, 09:18:14
Post
#15
|
|
Grupa: Zarejestrowani Postów: 461 Pomógł: 32 Dołączył: 17.09.2003 Skąd: Łódź Ostrzeżenie: (0%) |
jarek_bolo: niestety Twój pomysł byłby o wiele mniej wydajny niż chociażby składowanie sesji w bazie danych z ręcznym mechanizmem blokowania.
Problemem jest to, że jeśli dasz header location to on wraca do przeglądarki i ona robi ponowny request - więc idzie przez load balancer. Jeśli nawet dasz request wewnętrznie za pomocą na przykład curla to odpowiedź na zapytanie spowodowuje przynajmniej dwukrotnie większy ruch. pozdr. Łukasz |
|
|
6.08.2008, 09:45:00
Post
#16
|
|
Grupa: Zarejestrowani Postów: 10 Pomógł: 1 Dołączył: 18.07.2007 Ostrzeżenie: (0%) |
A jeśli chodzi o ruch wewnętrzny to napisałem, że header-locatiowanie miało by operować na subdomenach, które były by unikalne dla każdego z serwerów, a mod_rewrite docelowego serwera spowrotem przepisywał by na główną domenę. A więc load balancer musiał by reagować tylko przy requeście z główną domeną, a requesty subdomenowe wymuszone przez przekierowanie header-location powinny już trafiać zgodnie z adresem, bez load balancowania. Ale z racji swojego małego doświadczenia nie wiem czy tak się da i może głupoty piszę Hmm... raz to oczywiście podwójny ruch, dwa to... widziałeś kiedyś, w swoim pasku adresu, takie domeny: s123.google.pl, s345.nasza-klasa.pl, albo s333.youtube.com ? :-) |
|
|
6.08.2008, 10:13:25
Post
#17
|
|
Grupa: Zarejestrowani Postów: 535 Pomógł: 27 Dołączył: 3.05.2005 Ostrzeżenie: (20%) |
A co z adresami typu www2.cos.pl ?
|
|
|
6.08.2008, 10:18:46
Post
#18
|
|
Grupa: Zarejestrowani Postów: 461 Pomógł: 32 Dołączył: 17.09.2003 Skąd: Łódź Ostrzeżenie: (0%) |
Widziałem ale jeśli mam być szczery to to jest rozwiązanie słabe.
Załóżmy, że na każdy serwer (a mamy ich powiedzmy 10 sztuk) trafi po 50 użytkowników. Może się zdarzyć, że na jeden serwer trafią użytkownicy co będą odświeżać stronę raz na 5 minut (bo czytają w tym czasie regulamim, forum, cokolwiek) ale może się też tak zdarzyć, że na jeden serwer trafią użytkownicy co będą mieli odświeżenie co 10 sekund (bo na przykład wysyłają ataki w grze). I właśnie w grach widziałem to rozwiązanie i ono było za słabe. Prizee.com z tego korzystało (i chyba jeszcze korzysta) ale już pracują nad przebudową infrastruktury. Statyczne (przy pierwszym żądaniu w ramach sesji) przypisanie użytkownika do serwera jest najprostszym i na mój gust najgorszym rozwiązaniem. pozdr. Łukasz |
|
|
6.08.2008, 11:38:17
Post
#19
|
|
Grupa: Zarejestrowani Postów: 535 Pomógł: 27 Dołączył: 3.05.2005 Ostrzeżenie: (20%) |
Ale jak działa to
www2.cos.pl itd. bo nawet nie wiem jak o to google zapytać. Ten post edytował wlamywacz 6.08.2008, 11:38:39 |
|
|
6.08.2008, 11:41:48
Post
#20
|
|
Grupa: Zarejestrowani Postów: 461 Pomógł: 32 Dołączył: 17.09.2003 Skąd: Łódź Ostrzeżenie: (0%) |
Normalnie Serwer ma taką nazwę, dns wskazuje na jego IP. Tak jak każdy inny serwer
Nie rozumiem pytania pozdr. Łukasz |
|
|
Wersja Lo-Fi | Aktualny czas: 26.09.2024 - 17:47 |