Gra internetowa - hierarchia klas Opcje

[Ace]

Przeczytaj dokladnie to co napisalem.

Baza to podstawa, a twoja watpliwosc to cache? heh

[KOMPsognat]

Racja. Nie dopatrzyłem tego cache :]
Nie muszę mówić, że zmęzenie, pośpiech itp... ?

Myślę, że temat jest już do zamknięcia (nie wiem jak inni)

Ten post edytował KOMPsognat 15.02.2007, 14:28:57

[KG-]

Przeczytaj dokladnie to co napisalem.

Baza to podstawa, a twoja watpliwosc to cache? heh

Pozwolisz że zapytam - cache zapytań masz na czym? Na plikach? No chyba że na memcache, co i tak nie zmienia faktu że memcache także ma ograniczone możliwości (choć przyznam że są one ogromne).

Druga kwestia - wyobraź sobie że coś zmieniasz, np statystyki przedmiotu (co w dorosłej produkcji robi się bardzo rzadko - gracze nie cierpią gdy zmienia się coś w trakcie rozgrywki i przy pierwszej okazji cię za to zagryzą, zwłaszcza jeśli płacą za grę) i zmieniasz to na 500 serwerach. Teraz musisz połączyć się do 500 serwerów, wykonać zapytania a potem jeszcze dodatkowo uruchomić skrypt który wyczyści cache aby zmiany były widoczne. Musisz przy tym mieć ustawione w bazie danych by można się było łączyć z zewnątrz (mało bezpieczne rozwiązanie).
Zapisując dane w plikach odpalasz skrypt który wykonuje svn update po kolei na każdym serwerze a php acceleratory same zauważają że plik się zmienił. Oba rozwiązania są dobre ale to drugie wydaje mi się wygodniejsze na dłuższą metę (choć jest to kwestia gustu i przyzwyczajeń).
Pozdrawiam

Ten post edytował KG- 28.02.2007, 14:27:31

[dr_bonzo]

Teraz musisz połączyć się do 500 serwerów, wykonać zapytania a potem jeszcze dodatkowo uruchomić skrypt który wyczyści cache aby zmiany były widoczne. Musisz przy tym mieć ustawione w bazie danych by można się było łączyć z zewnątrz (mało bezpieczne rozwiązanie).
Zapisując dane w plikach odpalasz skrypt który wykonuje svn update po kolei na każdym serwerze a php acceleratory same zauważają że plik się zmienił.

Capistrano (http://manuals.rubyonrails.com/read/book/17 ): umozliwia ci wykonanie tych zamych (lub innych) zadan (skrypty schellowe) na wielu maszynach, obsluga SVN, laczy sie przez ssh. Trzeba dopisac wlasne taski (zadania -- czyli te skrypty updatujace) i update robisz jednym poleceniem

[Turgon]

Szczerze powiem jak update się robi, to tak czy siak jest to rzadkie... W przypadku zwłaszcza komercyjnych systemów Dlategóż, można też przyjąć strategię jak plemiona.pl . Nowy serwer = nowa wersja gierki

Ten post edytował Turgon 28.02.2007, 15:18:25

[KOMPsognat]

No właśnie ten cennik będzie dość często modyfikowany przy produkcji nowych gier. Mimo wszystko myślę jednak, że oparcie tego na plikach w formacie jaki pokazałem wcześniej będzie najlepszym rozwiązaniem.

Ten post edytował KOMPsognat 28.02.2007, 20:39:58

[Ace]

Hehe, a powiedz mi jaka jest roznica miedyz wykonaniem na 500 serwerach svn up... a uzyciem jakiegos skryptu bashowego ktory sciagnie tobie plik PHP z instalacja nowej wersji, ktory sam bedzie wiedzial jak zmigorwac caly system do nowej wersji. Czasem roznice w plikach, a czasem w bazie? A tak plik z update sciagasz sobie, z konsoli jest uruchamiany powiedzmy w nocy. Sciaga skrypt SQL, wykonuje go w transakcji + zmienia pliki kodu (Tu mozna uzyc np: svn up) i po ptakach...

Trzymanie wszystkiego w plikach textowych - uwierz mi, ze to sie nie uda. Po to wymyslil ktos baze danych, zeby tam skladowac potrzebne inforamcje, a nie rozrzucac je po katalogach na dysku w formacie plikow textowych... Cache powiedzmy moze sie odswiezac co jakis czas... np: Po takim update moze automatycznie cache byc kasowane.

@KG-:
Nie udostepniasz bazy na zewnatrz...

Logujesz sie po ssh, wykonujesz komende i tyle. Zawsze mozesz przemycic do kodu gry jakas akcje odpowiedzialna za update systemu. Cron co dzien w nocy laczy sie z twoim serwerem, sciaga definicjie xml'a, sprawdza czy jest nowsza wersja - JEST. Sciaga paczke, unzipuje, wykonuje komendy sql, wgrywa nowe pliki, uruchamia pliki php odpowiedzialne np: za skonwertowanie starej bazy do nowego formatu, przeprowadza testy jednostkowe, i jesli jest wszystko ok, to konczy proces.

Masz 500 serwerow - bo o takiej skali zaczoles mowic to ulatwi proces jeszcze bardziej niz zalogowac sie 500 razy i zrobic svn up...

Ten post edytował Ace 1.03.2007, 13:44:05

[KG-]

Trzymanie wszystkiego w plikach textowych - uwierz mi, ze to sie nie uda.

Uwierz mi że nie tylko się uda ale już się udało, działa bardzo ładnie przy 1000+ użytkowników jednocześnie

Masz 500 serwerow - bo o takiej skali zaczoles mowic smilingsmiley.gif to ulatwi proces jeszcze bardziej niz zalogowac sie 500 razy i zrobic svn up...

Ja nigdzie nie pisałem żeby się logować, można odpalać svn update zdalnie na wszystkich serwerach jednocześnie. Jakbym przy każdym update-cie się musiał logować na ssh po kolei na wszystkie serwery, to bym chyba jakiejś choroby nerwowej dostał

Jak pisałem wyżej - kwestia przyzwyczajeń, ja wychodzę z założenia żeby oszczędzać bazę i memcache bo one mają ważniejsze rzeczy do roboty niż wczytywać dane które się zmieniają raz na 2 miesiące albo rzadziej.

[Ace]

Czyli robiłeś testy i mówisz, że baza nie wytrzyma 1000+ użytkowników?

[KG-]

Wytrzyma czy nie wytrzyma to zbyt generalne pojęcie
Zależy która baza, jaki engine, na jakim sprzęcie, co musi zrobić w pojedynczym żądaniu itd.
Na mysql 4.1 bez cache-owania było już momentami ciężko przy ok 1400 użytkownikach jednocześnie (klikających w miarę często, w końcu to gra) na dedyku z 3gb ramu. Obciążenie bazy danych potrafiło osiągnąć 50-60%, po zastosowaniu memcache spadło do ok 15-25%. Mimo wszystko wolę zapisywać takie rzeczy w plikach, łatwiej mi edytować plik pod edytorem niż logować się do bazy i wykonywać zapytania + czyścić cache.

A jak ktoś nie używa memcache i robi cache na plikach, to wrzuca do bazy dane, które i tak zostaną zapisane w pliku i z pliku będą odczytywane. Kolejna kwestia - wolisz zapis w bazie ze względu na wygodę zmian - jak pisałem wcześniej w dorosłej produkcji nie dasz rady zmieniać czegoś co chwilę, gracze naprawdę nie lubią jak zmienia się coś w trakcie gry

Ten post edytował KG- 7.03.2007, 15:17:55

[Vogel]

MySQL lepiej sobie odpuścić do takich projektów. PostgreSQL albo MSSQL. Od kiedy przerzuciłem się na postgresa to mysqla wspominam tylklow koszmarach zupelnie inny komfort pracy

[mike]

~Vogel przerzuć się na wspomnianego przez siebie MS SQL'a. Dopiero będziesz miał koszmary. Ta baza to porażka.

W tej sytuacji PostgreSQL wydaje się być najlepszym rozwiązaniem.