Wdrożenie portalu społecznościowego.

[proweb]

Witam wszystkich.

Chciałbym uzyskać kilka informacji na temat wdrożenia sporego serwisu społecznościowego.

1. Projektuję serwis działający podobnie do znanego systemu aukcyjnego all....pl .Moje pierwsze pytanie dotyczy serwerów. Obecnie posiadam serwer dedykowany o następujących parametrach :

Procesor: Intel 1x Quad Core Xeon X3210

Pamięć RAM: 2GB DDR2 RAM

Dysk: 2 x 250GB SATA II

Transfer miesięczny: 2 TB

Łącze: 100 Mbps

System: CentOS, Debian, Fedora, Ubuntu, SuSe lub FreeBSD

Adresów IP: 2

Serwer firmy: Dell

Zewnętrzny Backup max 1plik tar.gz:

20 GB

Panel roboot

Instalacja: bezpłatna

Cena miesięczna: 360,0 zł

Podejrzewam, że na początek jest on wystarczający, ale patrząc przyszłościowo, zastanawiam się nada zakupem jakiejś docelowej maszyny. Bardzo prosiłbym o wskazanie dobrej serwerowni, która zaopiekuje się stroną serwerową i pozwoli na zwiększanie parametrów serwerów wraz z rozrostem serwisu.

2. Jak zabezpieczyć serwis przed niespodziewaną awarią. Co zrobić, aby nie utracić danych poprzez awarię serwera. Ew. jaką firmę polecilibyście, aby postawić równoległe kilka serwerów, aby dane były zapisywane w kilku miejscach automatycznie.

3. Zastanawiam się nad opracowaniem strategii marketingu dla portalu, którego wkład początkowy będzie wynosił ok.20 000 - 30 000 zł, chciałbym poradzić się nad formą inwestycji, oraz przede wszystkim uzyskać informacje, jak i gdzie bezpiecznie utrzymywać ten portal.

Chcę uniknąć wpadek serwisu typu Subasta, którego serwery nie wytrzymują i jakość usług jest na tragicznym poziomie. Nie interesuje mnie klonować alleg..., ale wykorzystam pewne podobieństwa i zastosowanie systemów aukcyjnych.

Z góry dziękuje za informacje, uwagi i spostrzeżenia.

[MMP]

Serwerownia to nie największy problem przy dużym obciążeniu, praktycznie większość oferuje podobny poziom usług, zabezpieczeń. Problemem są ludzie, potrzebujesz sprawnego admina serwerów który będzie potrafił zarządzać dużą ilością serwerów i programistów którzy potrafią napisać aplikację wieloserwerową. Weź przykład z nasza-klasa, ciągle dokładali serwery ale to nic nie dawało bo zwykłe dostawianie maszyny nic nie daje.

Najlepsi są u Kulczyka ;-)

[slawek22]

To czy masz serwer trochę lepszy czy trochę gorszy niewiele zmieni. Optymalizację PHP od razu można sobie odpuścić, chyba, że kod pisała jakaś niemota, moim zdaniem PHP może być niewydajny tylko jak go się umyślnie popsuje albo popełnia ewidentne błędy typu 40 kwerend / podstrona. Choćby nie wiadomo jak te kwerendy były proste i optymalne to SQL tego nie wytrzyma. PHP jest też niewydajny w idiotycznych syntetycznych benchmarkach (potem są durne artykuły i >porady< aby używać pojedynczych cudzysłowów zamiast podwójnych, bo w pętli 2 miliony powtórzeń się wykona pół procent szybciej )

Tak jak pisał MMP - aplikacja powinna być wieloserwerowa, liczy się głównie wydajność SQL. H/V Partitioning, odpowiednio dobrane klucze, brak konwersji typów w kluzulach where, nie używanie subqueries i between, etc. Jeśli nie da się zoptymalizować to wypadałoby chociaż, żeby dało się postawić SQL pracujący jako SLAVE (tutaj muszą być odpowiednio napisane kwerendy bo bazy się rozsynchronizują). SQL koniecznie na oddzielnym dysku (nie dzielonym z serwerem HTTP czy poczty), oddzielna subdomena/ip na CDN, koniecznie tagi expires/last-modified do keszowania (zamiast etagów, klient za każdym razem musi je sprawdzać, jeśli jest podana data - nie musi co odciąża serwer).

Jeszcze co do CDN to wypadałoby zamiast jednej subdomeny - kilka. Oczywiście nie posyłać tam ciastek. HTTP ma ograniczenie - 2 jednoczesne połączenia / subdomena, chyba że używasz niestandardowej przeglądarki. CSS Sprites, żeby ograniczyć HTTP.

Oddzielna subdomena do zapytań ajax (tam muszą iść ciastka). Z ajaxem jest taki problem że dotyczy go to samo ograniczenie co obrazków i jeśli jest ich dużo na stronie to żądanie może sobie czekać i minutę aż się doczytają obrazki albo nie wykonać się wcale. Wiele osób tego nie zauważa, bo skrypty js mają priorytet i muszą się wczytać wszystkie i wszystkie wykonać zanim przeglądarka zacznie robić cokolwiek innego (podobnie jak HTML, tutaj browser wykorzystuje renderowanie przyrostowe ale działa to praktycznie tak samo). Potem jest problem z ajaxem, bo programiści przyjmują, że jak każda ważna treść takie zapytanie pójdzie od razu a nie wskoczy na koniec kolejki zaraz po megabajcie obrazków.