Przygotowywanie skryptu - duży ruch.

[witko2006 0]

Witam.

 

Tak się ostatnio zastanawiam nad tym jakie 'zasady' wypadałoby przestrzegać i czym się kierować przy tworzeniu architektury np. strony internetowej ,aby w przyszłości gdy idea projektu okaże się sukcesem , można było dokładać po prostu sprzęt i nie być w sytuacji , w której konieczne jest przepisanie całego skryptu na nowo.

 

Jakie są wasze zdania na ów temat?

[m.p 0]

skalowalność, cache, optymalizacja.

[jurdziol 0]

Glownie buforowanie - najlepiej memcache, poniewaz wtedy zmniejszamy wykorzystanie dyskow. Aktualnie moc obliczeniowa i pamiec ram jest prawie za darmo.

 

Aby daleko nie szukac, w hetznerze za troche ponad 200 zl mamy i7 z 8GB RAM - Buforowanie czego sie da aby nie korzystac bezposrednio z dysku i taki serwer pociagnie naprawde duzy ruch.

[witko2006 0]

Przy okazji zapytam - co polecilibyście do sprawdzenia obciążenia procesora i ramu przez dany skrypt? Jakich danych potrzebowałbym jeszcze do obliczenia maksymalnej ilości wywołań|zapytań /s?

[m.p 0]

Przy okazji zapytam - co polecilibyście do sprawdzenia obciążenia procesora i ramu przez dany skrypt? Jakich danych potrzebowałbym jeszcze do obliczenia maksymalnej ilości wywołań|zapytań /s?

 

1 - htop/ps?

2 - najlepiej sprawdzić w rzeczywistości

[MiSi3kK 16]

Ad.2 ab

[GyniO 10]

-Jak najmniejsza ilość zapytań,

-Co się da upchać do cacha,

-Jak najlepsza struktura bazy,

-Używać crona do cięższych obliczeń.

[m.p 0]

btw, fajna prezentacja o zastosowaniu pythona i nie tylko w większych serwisach

 

http://www.polimetrix.com/pycon/slides/

[p 3]

Sorry, że odkopuję, ale nie mogłem się powstrzymać

 

Aktualnie moc obliczeniowa i pamiec ram jest prawie za darmo.

Nic bardziej mylnego... Powodem do cache'owania, denormalizacji baz danych i innych udziwnień jest właśnie fakt, że moc obliczeniowa nie jest "darmowa" i o wiele bardziej opłaca się precomputing / przechowywanie wyników w pamięci czy na dysku, niż obliczanie ich przy okazji każdego żądania...

[jurdziol 0]

Raczej mialem na mysli porownanie mocy serwerow np. 5 lat temu i dzis.

 

Powiedzmy dzis serwer za 10 tys. zl obsluzy nam znacznie wiecej zapytan niz ten z przed 5 lat, a zasobozernosc przecietnych operacji etralnie.

 

Nawet patrzac na Hetzner, dzis w cenie Athlona X2 mamy i7, na ktorym mozemy pociagnac naprawde duzy ruch. Przy aktualnej ilosci RAMu w serwerach mozemy wszystko buforowac za pomoca memcache. Znow patrzac na tani Hetzner mamy 8GB, wiec aby zapchac RAM danymi trzeba sie postarac.

 

Odpowiednio budujac oprogramowanie (rowniez z buforowaniem) i korzytajac z przecietnego serwera mozemy pociagnac naprawde duzy ruch. Stad moje 'prawie za darmo'

[tomii 0]

To na razie powiedzieliście co robić dla jednego serwera, a jakie są sposoby aby przygotować się do sytuacji że jeden serwer nam nie wystarczy?

[Gość Bartosz Gadzimski]

To na razie powiedzieliście co robić dla jednego serwera, a jakie są sposoby aby przygotować się do sytuacji że jeden serwer nam nie wystarczy?

W przypadku normalnie napisanych aplikacji webowych dokłada się wyspecjalizowane maszyny np. serwer www można rozbić na treść dynamiczną i statyczną (np. obrazki statyczne z hosta static.domena.pl), baza danych rozrzucana jest na kilka maszyn, poczta na osobną, dns również.

 

 

Takie proste rozrzucenie powinno wystarczyć na dość długo.

 

 

Następnie wykorzystuje się zaawansowane load ballancery i zewnętrzny cache albo duplikuje serwery.

 

Jeśli strona rośnie jeszcze bardziej to już trzeba tworzyć CDN albo pisać algorytmy rozproszone np. wykorzystując hadoop i Map Reduce (wykorzystuje flickr, facebook, yahoo).

 

Oczywiście nic nie zastąpi optymalizacji czy doboru oprogramowania np. Zeus zamiast Apache.

 

 

Strategii jest bardzo dużo, a ogranicza nas technologia (php + mysql nie ma takich możliwości jak java + oracle) i przede wszystkim nasza wiedza.

[m.p 0]

co do kilku serwerów, tak jak napisali poprzednicy:

- przerzucasz static/bazy danych na inne maszyny

- jeśli nadal serwery nie wyrabiają, interesujesz się tym, jak bardzo skalowalne są Twoje aplikacje, można bazę danych trzymać na dwóch maszynach (albo więcej), jeśli problemem nie okazuje się baza danych, możesz php/pythona/cokolwiek innego rozmieścić na kilku dedykach

- zainteresować się load-balance'ingiem (np nginx albo roubin-dns)

[tomii 0]

Czyli w samej aplikacji niewiele się robi.

Może napiszcie czego unikać w aplikacjach aby działały one jakoś na wielu serwerach.

[m.p 0]

od samej aplikacji dużo zależy - chociażby to, czy używasz dobrego cache, czy zawsze masz masę niezoptymalizowanych zapytań do bazy.

 

zainteresuj się skalowalnością języka, w którym piszesz, to będziesz wiedzieć, na co zwrócić uwagę, a czego unikać.