Temat: Skalowanie aplikacji JEE z dużym ruchem

Witam,
nie jestem pewien, ale chyba nie ma nigdzie na tym forum nic na ten temat.
Jeśli jest, to przepraszam za duplikat i proszę o link do niego :-)
Otóż, przygotowujemy się w firmie to stworzenia gry przeglądarkowej. Wiem, że większość robi backend w PHP, ale jakoś nie jestem przekonany do tego języka ze względu na dość dużą samowolkę programisty. Dlatego na 90% zdecydowałem się na JEE w backendzie. Nie jest to decyzja ostateczna, gdyź mam kilka wątpliwości. Zazwyczaj robiąc aplikacje JEE wystarcza jeden AS - np przy wdrożeniu w średniej firmie. Fakt faktem, zależy też co robi logika biznesowa, ale w większości przypadków to się sprawdza. W przypadku gry przeglądarkowej (udostępniona ma być na cały świat, w kliku językach) grono graczy może (ale wiadomo, nie musi) być bardzo duże.
Czy jest ktoś na tym forum, kto ma doświadczenie przy pracy z aplikacjami JEE o dużym ruchu rozłożonych na kilka maszyn z Tomcatem lub jakimś AS'em ?
Jeśli tak, to proszę o podzielenie się informacjami, czy taki połączenie robi problemy? Ewentualnie na co zwracać uwagę przy projektowaniu?
Czy może ktoś ma jakieś doświadczenie z aplikacjami o dużym ruchu nie tylko w JEE, ale i w PHP? Duży ruch - kilkadziesiąt tysięcy odsłon dziennie, lub więcej. Czy aplikacja napisana w PHP zajmie tyle samo, mniej, czy więcej zasobów serwera, co odpowiednik w JEE? Oczywiście obie napisane optymalnie. Czyli, generalnie, czy przy tej samej maszynie i tej samej funkcjonalności aplikacji PHP jest w stanie obsłużyć więcej użytkowników jednocześnie, czy JEE? Oczekuję tutaj raczej wypowiedzi popartych własnym doświadczeniem. Nie chodzi mi o wywołanie kolejnej wojny PHP vs. JAVA, ale o konkretne przykłady z codziennej pracy przy tego typu przedsięwzięciach wzięte.
Pozdrawiam :-)

Temat: Skalowanie aplikacji JEE z dużym ruchem

Witam,

Nie miałem styczności z aplikacjami o takim natężeniu ruchu ale mogę wypowiedzieć się jako znawca tematu od strony gracza (Na studiach sporo grałem w takie gry jak ogame czy desert operations) ;)

Otóż gry te, jak większość na rynku, oparta jest o silnik (PHP) z firmy LOOKI. Przyznaję się że do jednej z gier napisałem też bota. Większość problemów z wydajnością w tych grach dotyczyła nie tyle interfejsu użytkownika, co bazy danych. Jednak w przypadku desert-operations pojawił się zapis w OWG, że nieuzasadnione odświerzanie będzie karane. Domniemam, że zapis ten pojawił się w związku z ograniczeniami jakie narzuca PHP. Mianowicie, jeżeli skrypt wymaga 1MB pamięci na swoje wykonanie to jeżeli N userów w danej chwili wykonuje skrypt to zajętość pamięci wynosi 1MB x N. W przypadku JEE jest zgoła odwrotnie. Żeby było adekwatnie, servlet jest kompilowany raz i puszczane są na nim wątki a jako oddzielne instancje tworzone są tylko te zasoby, które mają być unikalne dla każdego usera. (Oczywiście w Tomcat można ustawić tryb taki jak w PHP). Na pierwszy rzut oka różnica jest niewielka ponieważ dotyczy tylko tego fragmentu, który wykorzystuje interpreter PHP plus ilość pamięci potrzebna na wczytanie skryptu. Przy okazji jest to dolna granica wykorzystania pamięci przez skrypt PHP. Gdzie jest zatem zysk? Im więcej rzeczy w servlecie zadeklarujemy jako static tym lepiej ponieważ zostaną one utworzone tylko raz na całe życie servletu. Czyli mamy K + M x N gdzie K to stała wynikająca z podstawowej ilości pamięci dla składowych statycznych, M - część unikalna względem użytkownika, N - ilość użytkowników.

Jeżeli potrzebujesz dowodu empirycznego polecam napisanie prostego skryptu w PHP i Servletu o tej samej funkcjonalności i poddanie ich stres testowi.

Temat: Skalowanie aplikacji JEE z dużym ruchem

Pracowałem przez długi czas przy aplikacji obsługującej paręset tysięcy klientów regularnie dobijających się do serwera. Jeżeli nie zamierzasz używać EJB czy web service'ów a jedynie gołych servletów to sprawa nie jest generalnie bardzo zagmatwana.

Najprościej zestawić Apache skonfigurowanego tak, żeby rozrzucał requesty po serwerach (konfigurowałem to z WebSpherem, który potrafi *automagicznie* wygenerować taką konfigurację, nie wiem jak jest w innych kontenerach). Zestawisz sobie parę serwerów i zewnętrzny serwer z bazą danych; wszystko połączone szybkim połączeniem sieciowym (użycie konfiguracji z managerem wirtualizacji np. vSphere czy Citrix byłoby najwygodniejsze).

Clustering takiej aplikacji jest bardzo prosty - specyfikacja JEE jest już bardzo dopracowana i nie ma praktycznie żadnych problemów przy środowisku clusterowanym. Są drobne niuanse, które trzeba znać przy pisaniu clusterowanej aplikacji np. kontekst aplikacji nie jest już jeden (znaczy jest - jeden per serwer :), więc nie możesz go już traktować jako miejsca np. na cache parametrów konfiguracyjnych.

Nie głupie pewnie będzie minimalizowanie ilości danych trzymanych w sesji (ja nie miałem takich problemów bo i tak nie trzymaliśmy nic w sesji) - po pierwsze przy dużej ilości użytkowników ta ilość się oczywiście multiplikuje (co jest mniejszym problemem - ram jest tani), za to klient przykleja się do serwera i trzeba migrować jego sesję, aby zmienić serwer.

Z taką konfiguracją (przy silnych serwerach, np jakiś AIXach na Power 7) można zajść dosyć daleko - na tyle daleko, że jeśli zaczynają się pojawiać poważne problemy performance'owe (zakładając oczywiście porządnie napisaną aplikację) - to znaczy, że odniosłeś naprawdę wielki sukces :) Później można jeszcze clusterować bazę, wrzucać całą bazę do RAMu (na serwerach z terabajtami ramu) czy przejść na storage z natury rozproszony. Ale to wszystko jest już daleko bardziej skomplikowane...

Temat: Skalowanie aplikacji JEE z dużym ruchem

Pawel Dolega:
Clustering takiej aplikacji jest bardzo prosty - specyfikacja JEE jest już bardzo dopracowana i nie ma praktycznie żadnych problemów przy środowisku clusterowanym. Są drobne niuanse, które trzeba znać przy pisaniu clusterowanej aplikacji np. kontekst aplikacji nie jest już jeden (znaczy jest - jeden per serwer :), więc nie możesz go już traktować jako miejsca np. na cache parametrów konfiguracyjnych.

Należy pamiętać, pisząc aplikację, ze najprawdopodobniej będzie używana serializacja obiektów pomiędzy serwerami, a używanie singletonów powinno być ograniczone do minimum. Co do sesji, to w środowiskach klastrowanych, np. w WebSphere istnieje możliwość utrwalania sesji w DB właśnie ze względu na to zastosowanie. W Tomcacie można skonfigurować "Session Clustering".
W klastrze, na cache parametrów konfiguracyjnych można użyć JNDI.Paweł Grotowski edytował(a) ten post dnia 18.04.11 o godzinie 07:17