Temat: najlepsza technologia dla ultra wydajnych serwisów www

Arkadiusz K.:
Amazon S3: US, Irlandia, Singapur i chyba Japonia ostatnio zostala dodana

Ja ostatnio stanalem przed wyborem firmy do obslugi eventu online z przewidywalnymi 50,000 requestami/sekunde i po dlugich poszukiwaniach wybor padl na Amazon AWS, niestety nigdzie indziej nie moglem znalezc tak latwo konfigurowalnych narzedzi do load balancingu, CDN i dokladaniu kolejnych instancji EC2, nie wspomne juz o konkurencyjnych cenach.

Odnosnie szybkosci serwowania danych to mam CDN wlasnie w Irlandii i nie ma problemow z szybkoscia (serwer w Polsce wpiety do PIX'a).
Dla calej Europy powinno byc bez problemow, pozostalych koncowek nie testowalem (jedynie East US) ale jesli masz klienta miedzynarodowego to amazon ma Amazon CloudFront dla CDN i nie przejmujesz sie gdzie jest klient, chmurka zaserwuje dane z najblizszej lokalizacji.

Jesli masz klienta w Australii to faktycznie edgecast ma tam koncowke, amazon nie ma

Dzięki za sugestie.

Klienci dokładnie z całego świata - ale głównie to europa centralna, półwysep indochiński, US, australia, ameryka południowa. Edgecast ma też dobre ceny dlatego chyba pójdziemy w te strone. U nas problemem jest też inny - musimy mieć rozwiazanie w pełni konfigurowalne - nie bazujemy tylko na serwowaniu statycznym. Dane sa często aktualizowane na CDNach.Mirosław Ratman edytował(a) ten post dnia 03.08.10 o godzinie 00:39

Temat: najlepsza technologia dla ultra wydajnych serwisów www

Jeżeli chodzi o CDN to musisz wybrać pod względem szybkości dla targetowych lokalizacji... API i dostępność też mają znaczenie....

Co do technologi to ja używam sprawdzonego zestawu PHP + memCache + postgres + apache ... na OVH RPS-3 (AMD Phenom 3core po 1.9GHz, 2 Gb RAM) robi bez problemu 1000 req/s (podstrona z produktami w katalogu) - testowane softem "siege". Na większych obciążeniach nie testowałem, ale staty serwera pokazują że ma jeszcze zapas.

Temat: najlepsza technologia dla ultra wydajnych serwisów www

Arkadiusz K.:

Bartłomiej Ogryczak:
2. Do statycznych plików lekkie, zdarzeniowe, asynchroniczne serwery (LigHTTPd, NGNiX),

to ja jeszcze dodam, wszystko co nie nie jest statycznym cachem dynamicznych tresci i nie musi byc trzymane lokalnie np css, js, img ladowac do zewnetrznego CDN ma Amazon S3, kosztuje to grosze i eliminuje setki tysiecy requestow do serwera

Jeśli chodzi o statyczne pliki, to niezbyt wypasiony (2 x 4cores) serwer potrafi obsłużyć jakieś 50-100K req/s. Kosztuje to znacznie mniej, niż S3. Jeśli postawi się w kolokacji gdzie będzie bezpośrednio przy DE-CIX (Frankfurt) albo AMS-IX (Amsterdam), to praktycznie na całą Europę masz doskonałą przepustowość.

Temat: najlepsza technologia dla ultra wydajnych serwisów www

Bartłomiej Ogryczak:

Arkadiusz K.:

Bartłomiej Ogryczak:
2. Do statycznych plików lekkie, zdarzeniowe, asynchroniczne serwery (LigHTTPd, NGNiX),

to ja jeszcze dodam, wszystko co nie nie jest statycznym cachem dynamicznych tresci i nie musi byc trzymane lokalnie np css, js, img ladowac do zewnetrznego CDN ma Amazon S3, kosztuje to grosze i eliminuje setki tysiecy requestow do serwera

Jeśli chodzi o statyczne pliki, to niezbyt wypasiony (2 x 4cores) serwer potrafi obsłużyć jakieś 50-100K req/s. Kosztuje to znacznie mniej, niż S3. Jeśli postawi się w kolokacji gdzie będzie bezpośrednio przy DE-CIX (Frankfurt) albo AMS-IX (Amsterdam), to praktycznie na całą Europę masz doskonałą przepustowość.

w przypadku statycznych plikow masz racje, mozna taka wydajnosc pewnie osiagnac ale jakos nie moge uwierzyc ze kolokacja takiego prywatnego CDNa jest tansza niz S3? jakis przyklad cenowy?

Temat: najlepsza technologia dla ultra wydajnych serwisów www

Arkadiusz K.:

Jeśli chodzi o statyczne pliki, to niezbyt wypasiony (2 x 4cores) serwer potrafi obsłużyć jakieś 50-100K req/s. Kosztuje to znacznie mniej, niż S3. Jeśli postawi się w kolokacji gdzie będzie bezpośrednio przy DE-CIX (Frankfurt) albo AMS-IX (Amsterdam), to praktycznie na całą Europę masz doskonałą przepustowość.

w przypadku statycznych plikow masz racje, mozna taka wydajnosc pewnie osiagnac ale jakos nie moge uwierzyc ze kolokacja takiego prywatnego CDNa jest tansza niz S3? jakis przyklad cenowy?

Powiedzmy, że masz średniej wielkości serwis, 1mln pageviews dziennie. Powiedzmy, że pageview to średnio sciągnięcie 20 statyków (img, CSS i JS), średnio po 20KB każdy. 400GB transferu i 20M requestów dziennie. Za coś takiego S3 skasuje 2-3K$/m. Coś takiego jest w stanie obsłużyć jeden serwer dedykowany za 100€/m. Nawet dodając drugi dla backupu i taki sam setup w drugiej lokacji i tak wychodzi z 10 razy taniej.

Temat: najlepsza technologia dla ultra wydajnych serwisów www

Bartłomiej Ogryczak:
Powiedzmy, że masz średniej wielkości serwis, 1mln pageviews dziennie. Powiedzmy, że pageview to średnio sciągnięcie 20 statyków (img, CSS i JS), średnio po 20KB każdy. 400GB transferu i 20M requestów dziennie. Za coś takiego S3 skasuje 2-3K$/m. Coś takiego jest w stanie obsłużyć jeden serwer dedykowany za 100€/m. Nawet dodając drugi dla backupu i taki sam setup w drugiej lokacji i tak wychodzi z 10 razy taniej.

zgadza sie, dla duzych serwisow jest to oplacalne ale...

IMO 400 GB transferu dziennie i 1mln pageview to nie jest sredni serwis :)
onet ma 77mln odslon dziennie i to jest czolowka, 400GB transferu rowniez brzmi bardzo nieprawdopodobnie, raz majac na uwadze ilosc danych a dwa cache-headers

na przykladzie jednego z moich serwisow, 10k pageviews daje ok 200k requestow i transfer ok 5GB dziennie co daje 24$ miesiecznie, realna ilosc requestow na dzien to ok 110k, zatem 90k leci z cachu przegladarki, co dalej zmniesza cene

przy miedzynaraodowych projektach bedzie miala znaczenie rowniez usluga CLOUDFRONT po stronie amazona, a mniej istotne dane moga byc umieszczone na reduced redundancy storage z 99,99% uptime co jeszcze bardziej zmniejsza cene

Temat: najlepsza technologia dla ultra wydajnych serwisów www

Arkadiusz K.:

Bartłomiej Ogryczak:
Powiedzmy, że masz średniej wielkości serwis, 1mln pageviews dziennie. Powiedzmy, że pageview to średnio sciągnięcie 20 statyków (img, CSS i JS), średnio po 20KB każdy. 400GB transferu i 20M requestów dziennie. Za coś takiego S3 skasuje 2-3K$/m. Coś takiego jest w stanie obsłużyć jeden serwer dedykowany za 100€/m. Nawet dodając drugi dla backupu i taki sam setup w drugiej lokacji i tak wychodzi z 10 razy taniej.

zgadza sie, dla duzych serwisow jest to oplacalne ale...

IMO 400 GB transferu dziennie i 1mln pageview to nie jest sredni serwis :)

Ok, średni w skali światowej ;-)

onet ma 77mln odslon dziennie i to jest czolowka,

Wydaje mi się, że więcej. Pare miesięcy temu chwalili się przekroczenem 3mld miesięcznie.

400GB transferu rowniez brzmi bardzo nieprawdopodobnie, raz majac na uwadze ilosc danych a dwa cache-headers

To zależy które ze statyków się powtarzają i jak często..

na przykladzie jednego z moich serwisow, 10k pageviews daje ok 200k requestow i transfer ok 5GB dziennie co daje 24$ miesiecznie, realna ilosc requestow na dzien to ok 110k, zatem 90k leci z cachu przegladarki, co dalej zmniesza cene

Ok, tyle, że w takim przypadku w ogóle nie potrzebujesz się przejmować osobnym serwerem dla statyków.

przy miedzynaraodowych projektach bedzie miala znaczenie rowniez usluga CLOUDFRONT po stronie amazona, a mniej istotne dane moga byc umieszczone na reduced redundancy storage z 99,99% uptime co jeszcze bardziej zmniejsza cene

Racja.Bartłomiej Ogryczak edytował(a) ten post dnia 25.08.10 o godzinie 18:10

Temat: najlepsza technologia dla ultra wydajnych serwisów www

Arkadiusz K.:
bardzo chetnie poznam szczegoly techniczne ultrawydajnosci, ilosc zuzywane pamieci, jakie rozwiazania zastosowano aby byl "ultrawydajny", jakie testy wykonano i ilu uzytkownikow /sekunde wykazal gorny limit przy jakim sprzecie

bez tego jest to wylacznie papka marketingowa, a jelsi system faktycznie jest dobry to warto to podac i nie na priv tylko tutaj

Wiem, że wątek już jakiś czas temu się "skończył" - jednak w związku z faktem, że przeprowadziliśmy testy, o których mowa (na razie COBAEX vs. Joomla) pozwalam sobie pokazać wyniki:

Testy wykonane za pomocą JMetera, serwerem była maszyna wirtualna 1 GB RAM stojąca na notebooku i3 M530 2,27 GHz, SATA HDD (przed każdym testem restart VM). Testowaliśmy stronę demonstracyjną Joomla.

1 test: 50 użytkowników / 1 sekunda, 10 powtórzeń (obydwa systemy nie wyrabiają się z obsługą żądań na bieżąco):
średni czas oczekiwania: Joomla - 10136ms; COBAEX CMS - 1317ms (7,7x szybciej)
mediana czasu oczekiwania: Joomla - 9528ms; COBAEX CMS - 1328ms (7,17x szybciej)
czas oczekiwania dla 90% próbek (poniżej): Joomla - 13653ms; COBAEX CMS - 1730ms (7,89x szybciej)

2 test: 50 użytkowników / 60 sekund, 10 powtórzeń (COBAEX CMS już obsługuje żądania na bieżąco, Joomla jeszcze nie):
średni czas oczekiwania: Joomla - 3740ms; COBAEX CMS - 26ms (143,85x szybciej)
mediana czasu oczekiwania: Joomla - 3935ms; COBAEX CMS - 24ms (163,96x szybciej)
czas oczekiwania dla 90% próbek (poniżej): Joomla - 5914ms; COBAEX CMS - 38ms (155,63x szybciej)

3 test: 50 użytkowników / 120 sekund, 10 powtórzeń (tutaj wygląda na to, że Joomla już obsługuje zapytania na bieżąco):
średni czas oczekiwania: Joomla - 170ms; COBAEX CMS - 29ms (5,86x szybciej)
mediana czasu oczekiwania: Joomla - 171ms; COBAEX CMS - 23ms (7,43x szybciej)
czas oczekiwania dla 90% próbek (poniżej): Joomla - 176ms; COBAEX CMS - 26ms (6,77x szybciej)