Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Zasady pisania na forum Pro

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.

3 Stron V   1 2 3 >  
Reply to this topicStart new topic
> Duże aplikacje i load balancing, Czyli co i jak zrobic jak maszyna nie daje rady
kwiateusz
post 2.08.2008, 18:53:14
Post #1


Admin Techniczny


Grupa: Administratorzy
Postów: 2 068
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
Go to the top of the page
+Quote Post
LBO
post 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".
Go to the top of the page
+Quote Post
wrauk
post 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...
Go to the top of the page
+Quote Post
Kocurro
post 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 smile.gif
Go to the top of the page
+Quote Post
wlamywacz
post 5.08.2008, 12:25:49
Post #5





Grupa: Zarejestrowani
Postów: 535
Pomógł: 27
Dołączył: 3.05.2005

Ostrzeżenie: (20%)
X----


A jest możliwość utworzenia dysku sieciowego i na nim trzymania sesji tak że każdy serwer będzie miał do niego dostęp ?
Go to the top of the page
+Quote Post
Kocurro
post 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
Go to the top of the page
+Quote Post
wrauk
post 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.
Go to the top of the page
+Quote Post
Sedziwoj
post 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%)
-----


Cytat(wrauk @ 5.08.2008, 13:55:10 ) *
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.
Go to the top of the page
+Quote Post
wlamywacz
post 5.08.2008, 21:09:04
Post #9





Grupa: Zarejestrowani
Postów: 535
Pomógł: 27
Dołączył: 3.05.2005

Ostrzeżenie: (20%)
X----


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 ? guitar.gif
Go to the top of the page
+Quote Post
mike
post 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%)
-----


Cytat(wlamywacz @ 5.08.2008, 22:09:04 ) *
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 ? guitar.gif
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ć.
Go to the top of the page
+Quote Post
wrauk
post 5.08.2008, 21:22:56
Post #11





Grupa: Zarejestrowani
Postów: 10
Pomógł: 1
Dołączył: 18.07.2007

Ostrzeżenie: (0%)
-----


Cytat(wlamywacz @ 5.08.2008, 22:09:04 ) *
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 ? guitar.gif

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).
Go to the top of the page
+Quote Post
jarek_bolo
post 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()?)questionmark.gif
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!!
Go to the top of the page
+Quote Post
wrauk
post 6.08.2008, 07:56:52
Post #13





Grupa: Zarejestrowani
Postów: 10
Pomógł: 1
Dołączył: 18.07.2007

Ostrzeżenie: (0%)
-----


Cytat(jarek_bolo @ 5.08.2008, 23:08:59 ) *
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.

Cytat(jarek_bolo @ 5.08.2008, 23:08:59 ) *
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 :-) ).
Go to the top of the page
+Quote Post
jarek_bolo
post 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%)
-----


Cytat(wrauk @ 6.08.2008, 08:56:52 ) *
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 smile.gif
Żałuję, że udzieliłem się w tym wątku przed przeczytaniem tongue.gif

Cytat(wrauk @ 6.08.2008, 08:56:52 ) *
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ę smile.gif


--------------------
"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!!
Go to the top of the page
+Quote Post
Kocurro
post 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
Go to the top of the page
+Quote Post
wrauk
post 6.08.2008, 09:45:00
Post #16





Grupa: Zarejestrowani
Postów: 10
Pomógł: 1
Dołączył: 18.07.2007

Ostrzeżenie: (0%)
-----


Cytat(jarek_bolo @ 6.08.2008, 09:51:23 ) *
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ę smile.gif

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 ?
:-)
Go to the top of the page
+Quote Post
wlamywacz
post 6.08.2008, 10:13:25
Post #17





Grupa: Zarejestrowani
Postów: 535
Pomógł: 27
Dołączył: 3.05.2005

Ostrzeżenie: (20%)
X----


A co z adresami typu www2.cos.pl ?
Go to the top of the page
+Quote Post
Kocurro
post 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
Go to the top of the page
+Quote Post
wlamywacz
post 6.08.2008, 11:38:17
Post #19





Grupa: Zarejestrowani
Postów: 535
Pomógł: 27
Dołączył: 3.05.2005

Ostrzeżenie: (20%)
X----


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
Go to the top of the page
+Quote Post
Kocurro
post 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 smile.gif Serwer ma taką nazwę, dns wskazuje na jego IP. Tak jak każdy inny serwer smile.gif

Nie rozumiem pytania

pozdr.
Łukasz
Go to the top of the page
+Quote Post

3 Stron V   1 2 3 >
Reply to this topicStart new topic
1 Użytkowników czyta ten temat (1 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Wersja Lo-Fi Aktualny czas: 18.08.2019 - 00:28