Wymagania serwerowe pod serwis

Witam!

Ciekawe czy ktos z Was ma doswiaczenie jakie moga byc wymagania sprzetowe pod serwis z 1,5 mln uzytkownikami tygodniowo (~30 mln odslon). Ciezko mi jest naprawde powiedziec, bo nie znam "od wewnatrz" strony ktora ma taki ruch wiec ciezko mi jest okreslic. Na pewno na poczatku 1 serwer pod baze (MySQL na poczatek - nie wiem czy wyciagnie - wersja 5.1), 1 pod pliki, 1 obslugujacy HTTP.

no dobrze, ale czy 1 starczy? I jakie wymagania sprzetowe powinien spelniac?

Ma ktos jakies rozesnanie w tej sprawie? Domysly?

można wzorować się nap na nasza-klasa.pl, tam z tego co mi wiadomo śmiga około 85 serwerów.
Przy Twoich liczbach stawiałbym jednak na parę maszyn, a wymagania? :) Dużo procesora, dużo RAMu, dużo łącza, pojemność dysków wedle potrzeb...

Należy mieć na uwadze "wąskie gardła". Na nic łaćze rzędu 10G/s skoro procesor nie poradzi sobie z przeprowadzaniem obliczeń, na nic "tysiąc" procesorów, skoro baza danych ma mało pamięci do wykorzystania...

no zapomnialem napisac cos o samym serwisie. Generalnie (nieskromnie mowiac ;)) jest dosc optymalny. Tzn. na moim (srednim) komputerze strony generuja sie w czasie 0,05 sek. No ale w bazie prawie danych nie ma ;)

Na kazda wygenerowana strone przypada kilka zapytan SQL. Sa to proste zapytania (pobieranie komentarzy, tresci tekstow itp.). Zdecydowana wiekszosc (90%) to zapytania SELECT. UPDATE tylko przy uaktualnianiu licznika odwiedzin tekstu ;) Inne UPDATE oraz DELETE w panelu administracyjnym, a jak wiadomo - az tak czesto tam sie nie zaglada. Stosuje cache, PHP optmizer...

@lofix: no ale nasza klasa ma 150 mln odslon dziennie z tego co mi wiadomo. Wiec az takich wymagan sobie nie stawiamy.

Load balancing? no bo kilka serwerow to sie zgodze np. na pliki. Tam liczy sie przestrzen dyskowa, ramu i procka duzo byc nie musi.

Co prawda wszystko wyjdzie w praniu, ciezko cos przewidziec, ale czy np. "duzo" na taka liczbe odslon to 4GB, 8GB RAMu?

1. Jak duża część jest dynamicznie generowana?
2. Jak wiele i jak ciężkie zapytania lecą do bazy?
3. W czym jest napisane?
4. Czy wykorzystujesz cachowanie?

Aktualnie siedzę przy serwisie, który chodzi na 1 serwerze MySQL, 2 serwerach HTTP. Na serwerach HTTP siedzi po jednym nginx-ie + po jednym memcached. Pliki statyczne serwowane są niezależnie przez klaster serwerów. Całość wytrzymuje blisko 1000 zapytań na sekundę.

Ogólnie rzeczy które warto rozważyć:

1. Pliki statyczne postawić na jakimś oddzielnym lekkim serwerze HTTP (nginx, lighttpd)
2. Jeżeli generujesz dużo danych dynamicznych to cachować ile się da (najlepiej postawić memcached na tym samym kompie co serwer http. memcached zjada pamięć, serwer http procka)
3. Odchudzić liczbę zapytań do bazy jak bardzo się da. W przypadku MySQL musisz jednak uważać ze zbyt skomplikowanymi zapytaniami, bo dostaje czkawki. Lepiej więcej prostych zapytań, niż jedno duże. W przypadku PostgreSQL odwrotnie.
4. Zależnie od tego w czym to jest napisane, rozważ różne metody uruchamiania (mod_*, fcgi itp.)

Ogólnie radzę przenieść możliwie najwięcej obciążenia z bazy na serwer http. Łatwiej jest dostawić serwer http niż zwiększyć wydajność bazy. Dobrze jest mieć 2 bazę w zapasie chodzącą np. jako slave (na wypadek awarii). I zacznij od prostej konfiguracji, a w razie potrzeby dostawiaj kolejne serwery (+ optymalizuj).

Adam Boduch napisał(a)

Co prawda wszystko wyjdzie w praniu, ciezko cos przewidziec, ale czy np. "duzo" na taka liczbe odslon to 4GB, 8GB RAMu?

4GB powinno spokojnie wystarczyć dla serwera http. Jeżeli większość to masz selecty to nie ma co się za bardzo przejmować.

Nauczony doświadczeniem, chciałbym jednak przestrzec przed tym updatem licznika odwiedzin. Parę tygodni temu taki update mało nie wykończył nam bazy. Przy updacie lock na tabeli był zakładany i przy dużej liczbie odwiedzin coraz bardziej wydłużał się czas odpowiedzi. Ostatecznie zrobiliśmy to przez licznik w memcache-u i aktualizowanie wpisu w bazie co jakiś czas.

Dryobates napisał(a)

Przy updacie lock na tabeli był zakładany i przy dużej liczbie odwiedzin coraz bardziej wydłużał się czas odpowiedzi. Ostatecznie zrobiliśmy to przez licznik w memcache-u i aktualizowanie wpisu w bazie co jakiś czas.

btw, MySql nie lock'ów na poziomie rekordu?

Co do tematu - mam pytanie, czy masz jakieś szczególne plany co do podsystemu dyskowego - RAID, etc? Pod jakim OS'em ma to chodzić? I czemu MySql?

Jakbyś to robił na Postgresie, to mam aplikację do automatycznego zakładania indeksów na bazie i "clustrowania" tabel. Wystarczy podłączyć do bazy i wpisać zapytania, albo zassać je z logu (ale wtedy trzeba wcześniej włączyć logowanie zapytań), kliknąć jeden guzik i po kilku sekundach podaje jakie indeksy trzeba założyć, a które są niepotrzebne.

Można też zoptymalizować bazę pod konkretne, docelowe wielkości tabel - tj. teraz masz mało użytkowników, ale zakładasz, że będzie dużo, więc dajesz mu że np. w tabeli z userami będzie tyle a tyle rekordów i to uwzględnia. Na razie wersja beta, ale już da się używać w praktyce. Kiedyś pisałem o tym na forum.

Do MySQLa wersję będę miał później, bo nie jest to w tej chwili dla mnie priorytetowe. Zresztą w MySQLu prawie nie ma co optymalizować, bo on i tak mało umie. Z drugiej strony do MySQLa brakuje tylko wtyczki do importu logów zapytań i schematu bazy wraz ze statystykami optymalizatora*, więc jeśli byłbyś bardzo zainteresowany, mógłbyś dopisać ;)

*) Nie wiem, czy z MySQLa da się wyciągnąc - z Postgresa dało się bez problemu, bo on wyniki ANALYZE trzyma w tabelach systemowych. W razie czego trzeba policzyć pewne rzeczy z danych, ale to jest wolne.

Dzieki za odpowiedzi.

A wiec jezeli chodzi o technologie to jest to PHP (bedzie z eAcceleratorem). Czemu MySQL? Tak klient chcial. Ale w razie potrzeby w przyszlosci nie bedzie problemu z podmiana bazy danych.

No wlasnie nie jest to jakis skomplikowany serwis, baza nie wymaga skomplikowanych zapytan. Ot co, wykorzystuje transakcje, klucze obce, aby zapewnic integralnosc danych. Ale sa to raczej proste selecty pobierajace tylko dane (zawartosc tekstow, komentarzy). Nie jest ich tez wiele (mniej niz 10, zalezy od podstrony). Nieraz w zapytaniach uzywane sa JOIN'y, ORDER, LIMIT ale zadnego GROUP itp.

@Dryobates: Cachowania uzywam (opartego o PHP - wlasna klasa), ale masz racje - memcached bedzie lepszym pomyslem. Jezeli mowisz ze 4 GB powinno starczyc na HTTP, to jak myslisz, ile na baze? Aha, i ten serwis nad ktorym teraz siedzisz: jaki ma ruch? Albo jaki ruch jest planowany?

System operacyjny to prawdopodobnie bedzie to jakis *nix, nie wiem tego jeszcze.

casual coder napisał(a)

Dryobates napisał(a)

Przy updacie lock na tabeli był zakładany i przy dużej liczbie odwiedzin coraz bardziej wydłużał się czas odpowiedzi. Ostatecznie zrobiliśmy to przez licznik w memcache-u i aktualizowanie wpisu w bazie co jakiś czas.

btw, MySql nie lock'ów na poziomie rekordu?

Tak, tak, na poziomie rekordu :) Moja pomyłka. Chodzi o to, że ten sam użytkownik miał wiele odwiedzin i wtedy nie wyrabiało.

Adam Boduch napisał(a)

Aha, i ten serwis nad ktorym teraz siedzisz: jaki ma ruch? Albo jaki ruch jest planowany?

Planowane jest dla ok. 3 mln użytkowników, ale oczywiście przy większej liczbie serwerów.

Hmm... ale rozumiem 3 mln uzytkownikow, nie wizyt? :) I to tygodniowo czy miesiecznie?

Dryobates napisał(a)

casual coder napisał(a)

Dryobates napisał(a)

Przy updacie lock na tabeli był zakładany i przy dużej liczbie odwiedzin coraz bardziej wydłużał się czas odpowiedzi. Ostatecznie zrobiliśmy to przez licznik w memcache-u i aktualizowanie wpisu w bazie co jakiś czas.

btw, MySql nie lock'ów na poziomie rekordu?

Tak, tak, na poziomie rekordu :) Moja pomyłka. Chodzi o to, że ten sam użytkownik miał wiele odwiedzin i wtedy nie wyrabiało.

Tylko jeśli używasz InnoDB. MyISAM ma blokady na poziomie całych tabel. Ale Ty chyba i tak bedziesz uzywał InnoDB, bo skoro mają być transakcje, to na MyISAM się nie da.

Krolik napisał(a)

Jakbyś to robił na Postgresie, to mam aplikację do automatycznego zakładania indeksów na bazie i "clustrowania" tabel.

Mógłbyś gdzieś wystawić tą aplikację ?

@nediam: Ok, ale bez kodu źródłowego i tylko do użytku prywatnego/niekomercyjnego (w celach do testów). Zresztą produkt jest w fazie alfa - nie chcę go wypuszczać przedwcześnie. Wiele rzeczy jest niedorobione i użytkownicy mogliby odnieść złe pierwsze wrażenie. Daj namiary na priv, to jak będę miał jakąś w miarę stabilną wersję, to Ci wyślę.

Poza tym:

1. Przed rozpowszechnieniem kodu źródłowego wolałbym najpierw opublikować użyte algorytmy w jakimś dobrym piśmie lub konferencji zagranicznej, bo boję się, że jeśli zrobię odwrotnie ktoś ściągnie te pomysły i opublikuje przede mną.
2. Nie mam jeszcze ustalonego na jakiej licencji chcę to rozpowszechniać. Na pewno będzie jakaś darmowa wersja do użytku niekomercyjnego. Ponieważ nie ma czegoś takiego na razie na rynku, muszę zrobić rozeznanie ile za to byłyby skłonne dać firmy hostingowe i firmy budujące systemy.

Krolik: niestety ale nie mogę się dopatrzeć PM na forum :|
Tak wiec mój mail to nediam na o2 :)

// wchodzisz w swój profil -> wiadomości -> napisz wiadomość - Cold