W jakiej technologii pisze się teraz aplikacje webowe?

1

Ostatnio naszla mnie ochota napisania gry przegladarkowej, takiej srednio zaawansowanej. Jedyna technologia w tym zakresie z jaka mialem doswiadczenie to PHP, ale nawet nie myslalem o pisaniu czegokolwiek w tym "jezyku programowania". Jako ze od dawna siedze w Javie to pomyslalem o czyms zwiazanym z Java no i po kilku googlowaniach wybor padl na Spring Framework. Zaczalem sie uczyc (nawet ksiazke kupilem opisujaca ostatnia wersje) i doszedlem do wniosku ze wszystko idzie w nim niezwykle topornie. Prawdopodobnie to kwestia przywyczajenia i doswiadczenia, ale jednak jesli wyswietlenie prostego "Hello World" zajmuje kilka klas i sporo linii konifguracji w plikach xml to chyba cos nie bardzo.. I nie przynudzajac, uznalem ze Spring to za wysoka poprzeczka (przynajmniej na to co zamierzalem w nim napisac).
Troche czasu juz od tego minelo (wrocilem do aplikacji desktopowych) ale ostatnio naszla mnie taka refleksja, no i pytanie do osob siedzacych w temacie. Jakie technologie sa przyszlosciowe? Slyszalem o Django, Ruby On Rails ale czytalem nawet o jakims wytworze od Googla ktory pozwala pisac jednoczesnie frontent i backend w JavaScripcie (czy jakos tak) i w ogole wydaje sie strasznie zaawansowany (szkoda ze nazwy zapomnialem, ale pewnie wiekszosc z Was bedzie kojarzyc i zaraz mi przypomni).
Zapewne jak zwykle wszystko chaotycznie napisalem i nikt nic nie zrozumie wiec zapytam prosto - jakie technologie sa przyszlosciowe w zakresie pisania aplikacji internetowych?

2

Jeśli nie boisz się poznawać nowych języków (a z postu wynika, że się nie boisz) to możesz spróbować np języka Scala i frameworka Play Framework. Jako że Scala jest nastawiona na integrację z Javą, to twoja aktualna wiedza będzie bardzo przydatna.

;]

0

Technologia Google o której mówisz to GWT, ale w praktyce chyba nikt nie korzysta z niej bezpośrednio tylko poprzez GXT, Vaadina.

Jeśli chodzi o Springa to początkowy narzut jest, ale później jest już z górki. No i licz się z tym że masz dużo więcej rzeczy dostępnych od razu -> transakcje, integracje z bazą danych i JPA, security, konwertowanie z /na jsona etc. Fakt że hello world będzie bardziej skomplikowany niż w PHP, ale już jakaś średniej wielkości aplikacja moze okazać się dużo wygodniejsza w tworzeniu.

3

Heh raczej nie spodziewaj się tutaj obiektywnej recenzji technologii webowych, ponieważ każdy będzie chwalił te technologie, które zna i lubi. Jeżeli poznasz dobrze którąkolwiek z wymienionych tu technologii to z pewnością odnajdziesz się w innej, ponieważ generalne założenia są dla wszystkich podobne i większość jest oparta na wzorcu MVC, ponadto wiele z nich od siebie wzajemnie zapożycza. Jednym z najstarszych i najbardziej udanych frameworków jest Ruby on Rails, ale jeżeli znasz teraz np. PHP i chcesz czegoś bardzo podobnego do "railsów" w tym języku to masz CakePHP, z kolei fani języka Python "railsy" znajdą w Pylons, a zwolennicy Javy czy Scala znajdą elementy "railsów" i django w frameworku Play.

Trudno powiedzieć co będzie najbardziej popularne za kilka lat i co jest najbardziej przyszłościowe. Jeżeli myślisz o pracy to raczej nie ma tu dużych różnic, ponieważ w każdej popularnej technologii wakatów jest więcej niż chętnych w nich pracować, choć najwięcej ofert jest dla programista J2EE i .NET. Z kolei jeżeli myślisz o własnym startupie to istnieje wiele udanych przedsięwzięć w każdej z tych technologii, choć najbardziej znane powstawały w PHP, Pythonie i Ruby. Startup da się robić nawet z wykorzystaniem stosu MS, ponieważ zarówno Visual Studio jak i SQL Server mają wersje darmowe, poza tym MS daje swoje płatne oprogramowanie, a nawet jakąś tam quota w chmurze Azure nowym firmom za free przez 3 lata (Bizspark).

Przykłady udanych startupów i wykorzystanych technologii:

  1. Reddit - Python + Pylons
  2. Dropbox - Python
  3. Instagram - Python + Django
  4. Flickr - PHP
  5. Facebook - PHP
  6. Basecamp - Ruby + Rails
  7. GitHub - Ruby + Rails
  8. Groupon - Ruby + Rails
  9. Twitter - Powstał w Ruby + Rails ale stopniowo przesiadają się na stos JVM, motywując to wydajnością i skalowalnością.
  10. LinkedIn - Java + Play
0

Duzych aplikacji nie "pisze sie w technologii X", duze aplikacje to ekosystem wielu zintegrowanych komponentow i one mogą być tworzone w najrózniejszych technologiach, które w danym kontekscie sprawdzą się najlepiej, ostatnio dość dobrze sprawdza się model BAAS, w którym na serwerze aplikacyjnym chula jedynie restfulowy serwis, a render wykonywany jest przez aplikacje frontową w przeglądarce lub na urządzeniu mobilnym. Polecam przyjżeć się Angular.js, Ember.js a na backendzie może być cokolwiek, PHP w zupełności daje rade, chociaż stos oparty o Jave ma przewagę jeżeli potrzeba prawdziwej konkurencyjności w systemie.

1
  1. Facebook - PHP

O FB było wiele razy. Wkopali się z PHP do takiego stopnia, że nie opłaca się tego przepisywać na coś sensownego i dlatego zmuszeni byli stworzyć kilka translatorów, kompilatorów i maszyn wirtualnych dla własnej okrojonej wersji PHP (ZTCP to np brakuje funkcji eval), by zmniejszyć narzut. Backend mają w C/ C++, Javie i chyba Erlangu, ale najwięcej backendu jest naklepane chyba w Javie. Być może jakieś inne języki też są szeroko używane.

Ogólnie takie Ruby, PHP czy Python są strasznie wolne i gdy trzeba obsłużyć duży ruch (niekoniecznie ciągle; mogą być spike'i w ruchu i to tez zabija serwery) trzeba ratować się modułami/ backendami w C/ C++, Javie czy innej platformie o dużej wydajności. Ale używanie zewnętrznych modułów napisanych w innych językach trochę wiąże ręce, więc myślę, że zdecydowana większość tych serwisów co podałeś ratuje się właśnie pisząc np własne mechanizmy do cachowania w C/ C++ lub modyfikując obecne.

chociaż stos oparty o Jave ma przewagę jeżeli potrzeba prawdziwej konkurencyjności w systemie.

Chyba chodziło o współbieżność/ równoległość?

0

@Wibowit - Stwierdzenie "O FB było wiele razy. Wkopali się z PHP" jest niefortunne. Nie wiem czy widziałeś "Social Network" ale Zuckerberg zainspirował się pomysłem trzech kolesi na stworzenie aplikacji społecznościowej i zamiast realizować ich pomysł na który dostał od nich zlecenie, zaczął tworzyć swoją bliźniaczo podobną stronę. Gdyby robił FB w Javie, to kolesie by się prawdopodobnie zdążyli zorientować nim Zuckerberg wypuści swoją aplikację ;)

0

No OK. Tak więc widać 2 drogi:

  1. Klepanie wszystkiego w Javie od początku, co powoduje, że czas stworzenia czegoś funkcjonalnego na samym początku jest dość długi, a więc istnieje ryzyko, że ktoś nas uprzedzi, albo zbankrutujemy zanim pomysł zacznie zarabiać na siebie. Za to w dłuższym okresie czasu wybór Javy zaczyna pokazywać zalety.
  2. Klepanie wszystkiego w PHP/ Pythonie/ Rubym od początku, co powoduje, że szybko stawiamy funkcjonalną implementację naszego pomysłu, potencjalnie ubiegając innych i zmniejszając ryzyko, że zbankrutujemy zanim pomysł przyniesie zyski. Problemy natomiast pojawiają się przy dużym obciążeniu, gdzie platformy typowo skryptowe nie wyrabiają, a projekt staje się trudny w zarządzaniu (IDE assistance w językach skryptowych jest nadal żałosne w produktach JetBrains w porównaniu do wsparcia w Javie).

Są jeszcze inne rozwiązania. Np na platformę Java są setki języków, w tym skryptowe, np Groovy lub JRuby, jak i statycznie typowane jak Scala. Można więc zacząć od Grooviego lub JRuby, a gdy pomysł chwyci płynnie przejść do Javy lub Scali. Poruszanie się w obrębie jednej platformy zdecydowanie ułatwia migrację z jednego języka na drugi jak i współpracę programów napisanych w różnych językach.

Na C# się słabo znam, ale sytuacja nie powinna mocno odbiegać od Javy. Z tym, że na platformę .NET chyba nie ma żadnego solidnego nieoficjalnego (tzn stworzonego poza MS) języka. Jest tylko C#, VB, F#, C++/CLI, etc z nich wszystkich strony klepie się chyba tylko w C# (?).

Wydaje mi się, że w żadnej z oficjalnych implementacji (czyli tych naklepanych w C) PHP, Ruby czy Pythona, nie ma obsługi współbieżności (rzeczywistej, czyli skalującej się z liczbą rdzeni). To kolejny argument przeciwko stawianiu serwisu o dużym obciążeni naklepanym w językach skryptowych.

0

Problemy natomiast pojawiają się przy dużym obciążeniu, gdzie platformy typowo skryptowe nie wyrabiają

Problemy przy dużych obciążeniach pojawiają się przez złą architekturę, a nie wykorzystania typowo skryptowych języków.

Wydaje mi się, że w żadnej z oficjalnych implementacji (czyli tych naklepanych w C) PHP, Ruby czy Pythona, nie ma obsługi współbieżności (rzeczywistej, czyli skalującej się z liczbą rdzeni). To kolejny argument przeciwko stawianiu serwisu o dużym obciążeni naklepanym w językach skryptowych.

Nie za bardzo. Współbieżność działająca na tradycyjnych wątkach jest potrzebna rzadziej niż się wszystkim wydaje. Zdecydowana większość przypadków, gdy potrzebna jest współbieżność to czekanie na IO, z czym większych problemów np. w Pythonie nie ma (dodatkowo ostatnio coraz bardziej popularne stają się narzędzia typu libevent). A działania CPU-bound, które potrzebują wielowątkowości w backendzie strony internetowej wskazują raczej na problem z architekturą właśnie. Ostatnio jest moda na bardzo lekkie backendy i jeżeli potrzeba gdzieś wykonać cięższą robotę to wynosi się ją do zewnętrznych serwisów (które mogą być już naklepane w Javie czy czymkolwiek innym). Tak wygląda właśnie zastosowanie PHP w Facebooku. Pobrać dane i je wyświetlić.

Na C# się słabo znam, ale sytuacja nie powinna mocno odbiegać od Javy. Z tym, że na platformę .NET chyba nie ma żadnego solidnego nieoficjalnego (tzn stworzonego poza MS) języka. Jest tylko C#, VB, F#, C++/CLI, etc z nich wszystkich strony klepie się chyba tylko w C# (?).

Najbardziej popularny jest zdecydowanie C#. Nie jest to chyba nic złego, bo to po prostu dobry i wygodny język. Część dinozaurów pisze jeszcze w VB.NET. Na popularności cały czas zyskują F# oraz IronPython (ten, o ile mnie pamięć nie myli, został stworzony jest byłego programistę Microsoftu, więc nieoficjalny jest tak "pół na pół" ;)).
Tak nawiasem mówiąc Microsoft w ostatnich miesiącach poszedł po rozum do głowy. Po pierwsze wziął się w końcu za ogarnięcie tego burdelu w kompilatorach JIT, których MS ma trzy różne implementacje z różnymi codebase. Odbijało się to IMO sporo na tym, że żadna z nich nie była wydajna (przynajmniej w porównaniu z JVM). Teraz codebase będzie jeden i, przynajmniej z tego co piszą, zaowocuje to między innymi porządnymi optymalizacjami w runtime (w końcu). Druga kwestia to coraz bardziej ścisła współpraca z Xamarinem, który coraz śmielej poczyna sobie na rynku mobile i mam nadzieję, że urodzi się z tego coś ciekawego.

1

@Wibowit: A po co Ci współbieżność w backendzie typowej aplikacji biznesowej, jak statystyczny request jest obsługiwany w 10ms? Balansujesz poszczególne requesty między kilkoma rdzeniami i działa. Przecież i tak największy zapierdziel ma baza danych. Daj jakiś życiowy przykład, kiedy potrzebujesz wielowątkowości w backendzie.

1

Wszelkie rodzaje cache, które służą przede wszystkim po to, by zmniejszyć ilość odwołań do bazy. Dzięki wielowątkowości wiele requestów może równolegle korzystać z cache w tym samym procesie (współdzielenie cache przez wątki zwiększa jego efektywność). Dzięki temu że cache znajduje się w tym samym procesie co serwis to żądania do cache są dużo szybsze, co zwiększa elastyczność tego cache.

Do tego dochodzi fakt iż wątki są znacznie lżejsze niż procesy, szybsze jest też ich tworzenie.

0

Tylko po co tworzyć te procesy/wątki non stop? Chodzi pula procesów/wątków, w każdym odpalony Python/PHP/wtf i działa. Po skończeniu obsługi requestu resetujesz stan i lecisz dalej, to powinno być szybsze niż stworzenie wątku/procesu od nowa.

Masz jakieś benchmarki w sprawie wewnętrznego cache? W przypadku nowoczesnych aplikacji z ładowaniem on-demand jeden request niesie garstkę danych, wyczuwam więc zysk na poziomie maksymalnie kilku milisekund.

2

I co, w twoich wszystkich projektach stosujesz memory cache in-proc? To rozwiązanie ma więcej minusów niż plusów i w większych wdrożeniach korzysta się z dystrybuowanych systemów cache.

1

Idąc tym tokiem myślenia zaraz dojdziemy do wniosku, że serwer do gry przeglądarkowej to tylko kilka zapytań SQL, które się automatycznie cache'ują, a PHP tylko przerabia dane z bazy na JSONa za pomocą wbudowanych funkcji. Podobnie FB i inne, a HipHopy i inne bajery stworzone prze FB to tylko fanaberie, bo i tak większość czasu serwery spędzają na czekaniu na bazę.

Typowa gierka przeglądarkowa jest podzielona na światy, gdzie jeden świat może siedzieć spokojnie w całości w RAMie na jednym serwerze, który to serwer może odpowiadać na setki żądań na sekundę. Robienie tego w PHP to zabójstwo dla maszyny.

Robiąc gierkę multi szedłbym właśnie w kierunku trzymania całego pojedynczego świata w jednym procesie, a bazy używał głównie jako backupu synchronizowanego przez logowanie zdarzeń na bieżąco (zdarzenie np typu: gracz X zadał Y obrażeń graczowi Z) i okresowe asynchroniczne przetwarzanie ich w celu minimalizacji zajętości bazy i czasu koniecznego na odtworzenie w przypadku padu serwera.

Robiąc gierkę single olałbym prawie całkowicie logikę server-side, tzn po stronie serwera zrobiłbym co najwyżej zapisywanie sejwów z opcjonalną autentykacją. Nie ma sensu nieustannie napieprzać po łączach w przypadku gierki single.

1

Wibowit, chyba w życiu nie projektowałeś dużej apki webowej, powiedz mi jak zamierzasz skalować rozwiązanie, które trzyma stan w ramie? Co z dostępnością? Co z wydajnością? Co jak ramu zacznie brakować? Co z limitami systemu? Co ze strefami dostępności? Co z wydajnością IO? PHP/Python/Ruby to kwestia wtórna, jak zjebiesz architekture i chocbyś to w gołym assemblerze klepał i tak bedzie zjeb*** i w sumarycznie wolniejsze niż kilka tanich węzłów dla języka skryptowego. Na siłę chcesz skalować wertykalnie i robić mikrooptymalizacje zamiast Od razu projektować system tak aby działał w trybie 2N + 1 i skalował się liniowo.

A i jedna istotna kwestia, nie spotkałem sie jeszcze aby to warstwa prezentacji była wąskim gardłem, nie spotkałem sie z tym, żeby to PHP czy inny język skryptowy i jego wydajność był a problemem, natomiast prawie zawsze wąskim gardłem był zapis i przetwarzanie danych...

1

Robiąc gierkę multi, której akcja dzieje się 'na żywo' napisałbym kompletnie oddzieloną od webu usługę. Połączenie jej z backendem www to byłby twój pierwszy błąd architektoniczny.

0

Napisałem żeby trzymać w RAMie bo przecież chodzi o gierkę multi, a nie drugiego Facebooka.

Jak byłem na rozmowie w Google, to jedno z pytań było o tym jak zaprojektowałbym jakiś tam serwis do oceniania piosenek. Jako że naczytałem się o BigTable i innych tego typu rzeczach to od razu przeszedłem do rozproszonych baz danych. Po drodze było dużo pytań, a co jeśli nagle liczba użytkowników się zwiększy, itd Na końcu jednak kolo zapytał czemu nie zapytałem o parametry, tzn ile będzie użytkowników, ile będzie danych etc Kazał mi policzyć zajętość pamięci i dla założonych danych wyszło coś rzędu 100 MB. To kompletnie podważyło zabawę w rozproszone bazy danych.

Dlatego trzeba najpierw zrobić założenia.

Z doświadczenia wiem, że największym problemem jeśli chodzi o przerabianie aplikacji jest zmiana schematu bazy danych. Dlatego wychodzenie wyobraźnią wiele miesięcy czy lat wprzód może zakończyć się źle jeśli zrobimy skomplikowaną strukturę bazy danych, która okaże się niewypałem.

Robiąc gierkę multi, której akcja dzieje się 'na żywo' napisałbym kompletnie oddzieloną od webu usługę. Połączenie jej z backendem www to byłby twój pierwszy błąd architektoniczny.

Ja omawiałem jak bym zrobił gierkę przeglądarkową, a nie Warcrafta.

Tak w ogóle to są jakieś gierki multi (obojętne czy przeglądarkowe czy nie, ważne żeby akcja była w miarę żwawa), gdzie jeden świat jest rozproszony na kilku serwerach? Mi jakoś nie przychodzą do głowy. Nawet WoW ma jeden serwer na jeden świat i średnio kilka tysięcy ludzi na jednym serwerze. Zakładając 100 KB danych na jednego użytkownika, wystarczy nawet jedna 32-bitowa JVMka do uciągnięcia czegoś takiego.

0
Wibowit napisał(a):

Jak byłem na rozmowie w Google, to jedno z pytań było o tym jak zaprojektowałbym jakiś tam serwis do oceniania piosenek. Jako że naczytałem się o BigTable i innych tego typu rzeczach to od razu przeszedłem do rozproszonych baz danych. Po drodze było dużo pytań, a co jeśli nagle liczba użytkowników się zwiększy, itd Na końcu jednak kolo zapytał czemu nie zapytałem o parametry, tzn ile będzie użytkowników, ile będzie danych etc Kazał mi policzyć zajętość pamięci i dla założonych danych wyszło coś rzędu 100 MB. To kompletnie podważyło zabawę w rozproszone bazy danych.

Super, zrobiłeś SPOF, jednym z założeń powinno być to, że system ma być dostępny zarówno w stanach jak i w europie, oraz w miare niezawodny i łatwy w utrzymaniu, dlatego mimo że 100MB ramu to pierd to ze względu na dostępnośc i czas realizacji projektu robienie tego z palca w ramie jest conajmniej głupie. I prosze Cie, Google to wielka firma i masa zdolnych ludzi ale gdybym nie widział od środka to może bym uwierzył, że wszystko co robią jest perfekcyjne ;)

Wibowit napisał(a):

Z doświadczenia wiem, że największym problemem jeśli chodzi o przerabianie aplikacji jest zmiana schematu bazy danych. Dlatego wychodzenie wyobraźnią wiele miesięcy czy lat wprzód może zakończyć się źle jeśli zrobimy skomplikowaną strukturę bazy danych, która okaże się niewypałem.
Tu akurat masz pełną racje, dlatego można pozbyć się schematu i relacji :)

Wibowit napisał(a):

Robiąc gierkę multi, której akcja dzieje się 'na żywo' napisałbym kompletnie oddzieloną od webu usługę. Połączenie jej z backendem www to byłby twój pierwszy błąd architektoniczny.

Ja omawiałem jak bym zrobił gierkę przeglądarkową, a nie Warcrafta.

Ostatnio modne jest websockets, troche kompromis, chociaż też ma swoje wady w produkcji.

Wibowit napisał(a):

Tak w ogóle to są jakieś gierki multi (obojętne czy przeglądarkowe czy nie, ważne żeby akcja była w miarę żwawa), gdzie jeden świat jest rozproszony na kilku serwerach? Mi jakoś nie przychodzą do głowy. Nawet WoW ma jeden serwer na jeden świat i średnio kilka tysięcy ludzi na jednym serwerze. Zakładając 100 KB danych na jednego użytkownika, wystarczy nawet jedna 32-bitowa JVMka do uciągnięcia czegoś takiego.
Ciężko mi uwierzyć, że WoW działa w oparciu o jeden węzeł bez żadnego failover lub load balancera, zwłaszcza, że to poważny biznes. A, i to że twoja maszyna łączy się zawsze z danym hostem po nazwie czy nawet IP nie oznacza, że jest jeden :)

0

Super, zrobiłeś SPOF, jednym z założeń powinno być to, że system ma być dostępny zarówno w stanach jak i w europie, oraz w miare niezawodny i łatwy w utrzymaniu, dlatego mimo że 100MB ramu to pierd to ze względu na dostępnośc i czas realizacji projektu robienie tego z palca w ramie jest conajmniej głupie. I prosze Cie, Google to wielka firma i masa zdolnych ludzi ale gdybym nie widział od środka to może bym uwierzył, że wszystko co robią jest perfekcyjne ;)

Ale z kim tutaj polemizujesz? Koleś wprost nakierował mnie na to rozwiązanie. Odniosłem wrażenie że wg niego to poprawne rozwiązanie. Zresztą nawet gdyby np moje oceny piosenek z ostatnich 5 sekund przepadły bez wieści to co to za problem? Widzisz problem tam gdzie go nie ma. Są dane bardziej i mniej wrażliwe.

Tu akurat masz pełną racje, dlatego można pozbyć się schematu i relacji :)

No i wtedy okazuje się że trochę te dane trzeba jednak mielić, bo bazka nam nie wypluje obrobionych danych.

Ciężko mi uwierzyć, że WoW działa w oparciu o jeden węzeł bez żadnego failover lub load balancera, zwłaszcza, że to poważny biznes. A, i to że twoja maszyna łączy się zawsze z danym hostem po nazwie czy nawet IP nie oznacza, że jest jeden :)

A niech będzie i potrójna replikacja. To nie spowoduje, że trzymanie całego świata w RAMie stanie się niemożliwe. Bo co to za problem mieć 3 serwery z identyczną zawartością RAMu?

Poszperałem na szybko w Googlu i wywnioskowałem, że światów w WoWie jest mnóstwo i są one określane mianem realm i generalnie jest proprocja 1 realm = 1 serwer (abstrahując od tego czy są serwery slave'y z kopią realmu, a pewnie są).

0
Wibowit napisał(a):

Ale z kim tutaj polemizujesz? Koleś wprost nakierował mnie na to rozwiązanie. Odniosłem wrażenie że wg niego to poprawne rozwiązanie. Zresztą nawet gdyby np moje oceny piosenek z ostatnich 5 sekund przepadły bez wieści to co to za problem? Widzisz problem tam gdzie go nie ma. Są dane bardziej i mniej wrażliwe.

Po prostu uważam, że to dupne rozwiązanie technicznie i biznesowo.

Wibowit napisał(a):

No i wtedy okazuje się że trochę te dane trzeba jednak mielić, bo bazka nam nie wypluje obrobionych danych.

Ale "obrabianie danych" to nie jest domena webu, web to interfejs.

Wibowit napisał(a):

A niech będzie i potrójna replikacja. To nie spowoduje, że trzymanie całego świata w RAMie stanie się niemożliwe. Bo co to za problem mieć 3 serwery z identyczną zawartością RAMu?
A ile bedziesz miał tego ramu? Moj serwerek testowy ma 64GB, łyknie jakies 256GB, do kupienia sa dzisiaj serwery z limitem +- 1TB a nawet ciut więcej. I co 1TB to dużo? TO W CH*J MAŁO! Jak masz kilkaset TB danych w produkcji to się zaczynają jazdy a niejedna organizacja ma ich wielokrotnie więcej. Wiesz jakie medium ma największy transfer obecnie? Samolot i dysk w kieszeni. Dosłownie, tak się kopiuje dane produkcyjne. Dorzuć do tego baze klientów i ich interakcje z systemem i SLA. Dzisiaj nawet infrastruktura jest "kodem", częśc ekosystemu to deployment i się go programuje (np: puppet, chef, itp), gołe serwery mają sie automatycznie instalować replikować i dołączać do puli aby utrzymać system. I co z tego, że językiem, który skleja komponenty jest PHP Ruby czy Java? To jest wręcz pomijalne...

W projekcie nad którym aktualnie pracuje mamy wydajność w produkcji na poziomie 2500 requestów na sekunde z jednego węzła przy transferze do ok 150mbit/s, skaluje się toto liniowo, działa w wielu geolokalizacjach na całym globie, jest kilka tricków fakt, ale technologia "webowa" to po prostu zwykły pehap, a z tyłu mamy wiele komponentów w javie, erlangu, c...

0

Ale jak to się ma do tworzenia gierki? Będziesz robił tysiące zapisów do bazy na sekundę i wymyślał kosmiczne architektury, żeby kilka tysięcy ludków sobie zagrało? Strzelasz z muchy do armaty.

No chyba, że autor tematu rzeczywiście chce tworzyć super wielkie czy super skomplikowane światy, 1000 razy bardziej złożone niż te w Warcrafcie.

0

Z tego co wiem (a o webdev przyznaje wiem niewiele) aktualna tendencja to odciążanie serwera ile się da - głównie dzięki Angular / JavaScript.
To czego nie da się zrobić na kliencie i wymaga dużej elastyczności, robi się w języku skryptowym na serwerze (Groovy, PHP, JavaScript).
A jeśli coś się da wydzielić architektonicznie i ma ustaloną strukturę API to robisz w czymkolwiek kompilowanym - Scala, Java, C#, C++ przez REST API lub websockets.

Jeśli chodzi o wydajność to ich braków nie zauważyłem w PHPie, mimo że nie jest to jakiś geniusz wydajności. Ale nic wielkiego nie robiłem.
Brak wątków jest dla mnie osobiście zaletą a nie wadą, bo mimo że lubię programować rozwiązania przetwarzające równolegle, to nigdy wątków nie lubiłem. Why?
Po prostu są przereklamowane, przegadane. Obecnie jest tyle prostszych rozwiązań, że dziwie się że jeszcze trzeba o tym wspominać.

W każdym razie, w RAM nigdy nie trzymałbym stanu gry. Nie dlatego że że uważam commity po każdym requeście za coś dobrego, ale dlatego, że ilość RAM z reguły zawsze jest niewystarczająca. Jak uniknąć trzymania wszystkiego -tylko- w RAM?

Odczyt - to jasne że cache (jeden lub dystrybuowany)
Zapis - buforowany zapis

Pewnie są jeszcze jakieś ciekawsze rozwiązania, ale idę na obiad :)

0

W każdym razie, w RAM nigdy nie trzymałbym stanu gry. Nie dlatego że że uważam commity po każdym requeście za coś dobrego, ale dlatego, że ilość RAM z reguły zawsze jest niewystarczająca.

Hmm, załóżmy że mamy 10k użytkowników, każdy wciąga 100k pamięci - wychodzi 1g zapotrzebowania na RAM. Statyczną zawartość można serwować z osobnych serwerów. Czy serwer z 1G pamięci jest tak strasznie drogi? Albo czy gierka będzie aż tak rozbudowana, że stan każdej postaci będzie liczony w megabajtach? Albo czy planujemy zrobić gierkę z gigantycznymi światami, większymi niż te np z WoWa?

A zapis trzeba oczywiście robić, jak już napisałem, ale można tylko logować zdarzenia przez np dopisywanie ich do kolejki trzymanej na dysku. Potem okresowo kolejkę opróżniać, łączyć dane i dopiero wtedy zapisywać do bazy hurtem.

Jeśli świat się nam przepełnia to robimy kolejny, na kolejnym serwerze i w d*pie mamy rozproszone bazy danych. Tak się robi w przypadku gierek multi, zarówno 3D jak i przeglądarkowych.

0

Jeśli chodzi o Rubiego i Railsy to w większości wypadków są one dość wydajne same w sobie. Jeśli są do zrobienia jakieś zadania bardziej wymagające to się używa jakiegoś narzędzia do odpalania procesów w tle (lub na innej maszynie) jak Delayed Job czy Sidekiq. Jeśli komuś nie starcza mocy zawsze może się przenieść na JRuby co można zrobić w części przypadków praktycznie z miejsca. Czasem może być konieczność wymiany gemów na wersje bez wstawek natywnych. Oprócz tego jest jeszcze Rubinius, który działa na podobnych zasadach jak PyPy. Jednak znaczną większość pracy da się wykonać w samym Rubym bez uciekania się do tak dramatycznych decyzji jak przesiadki na inne wersje. Większość da się zrobić na czystym Rubym 2.0.0 i ich wydajność (pod warunkiem sprawnie zaprojektowanego systemu) będzie aż nadto wystarczająca.

1 użytkowników online, w tym zalogowanych: 0, gości: 1