Co powinienem zrobić, aby skalować witrynę o dużym ruchu?

14

Jakie najlepsze praktyki należy podjąć w przypadku strony internetowej, która musi zostać „skalowana”, aby obsłużyć pojemność? Jest to szczególnie istotne teraz, gdy ludzie zastanawiają się nad chmurą, ale może brakować podstaw.

Chciałbym usłyszeć o wszystkim, co uważasz za najlepszą praktykę, od zadań na poziomie programistycznym, przez infrastrukturę, aż po zarządzanie.

goodguys_activate
źródło
1
Spójrz na: highscalability.com
Casebash
Czy ktoś, kto wie o systemie Windows Server App Fabric i buforowaniu, może coś tutaj zamieścić? Nie jestem ekspertem w tej dziedzinie i chcę dowiedzieć się więcej.
goodguys_activate 20.10.10
Co chcesz wiedzieć o AppFabric?
Henrik
Istnieje kilka wskazówek, jak skalować witrynę internetową, sprawdź to. Obejmuje: poziom skryptu serwera na poziomie frontonu Model i poziom projektu bazy danych Skalowanie w poziomie serwera, dzielenie Zobacz więcej: olivetit.blogspot.com/2013/05/…

Odpowiedzi:

16

Projekt dla współbieżności

Oznacza to, że podczas kodowania planuj uruchomienie wielu wątków. Zaplanuj stan współdzielony (często tylko db). Zaplanuj wiele procesów. Zaplanuj rozkład fizyczny.

Umożliwia to dystrybucję systemu na wielu komputerach i na wielu procesach z równoważeniem obciążenia. Pozwala to na uruchomienie nadmiarowych procesów w przypadku awarii, aw przypadku konieczności modyfikacji systemu w miejscu, nie musisz zabijać wszystkich usług, aby to zrobić.

Fishtoaster
źródło
13

Kilka rzeczy, które możesz rozważyć:

  • Oddzielanie stron zapisu i odczytu danych.
    • CQRS / Sourcing zdarzeń
    • CQS
    • Przekazywanie wiadomości / aktorzy
  • Unikanie wspólnego procesu i stanu wątku
    • Stąd unikanie blokowania
    • Można tego uniknąć dzięki systemowi typów, tworząc klasy, struktury i inne typy danych, które będą niezmienne, tzn. Nie ulegną zmianie po zbudowaniu. Zwłaszcza w przypadku złożonych abstrakcyjnych typów danych działa zaskakująco dobrze (np. Implementacja jQuery)
  • Nie blokuje wątków serwera WWW na IO. Jeśli używasz ASP.Net, użyj asynchronicznych stron / akcji z biblioteką wzorców / zadań równoległych APM (TPL)
  • Nie zapisywanie obciążeń stanu w słowniku sesji użytkownika
    • Należy to przenieść między wątkami, gdy migracja wątków występuje w IIS.
    • Posiadanie inteligentnego routingu, takiego, że niezabezpieczone / statyczne zasoby nie są obsługiwane w tej samej strukturze aplikacji (np. ASP.Net), która dodaje koszty ogólne. Spójrz na przykład na różne serwery sieciowe.
  • Pisanie kodu przekazywania kontynuacji przy użyciu asynchronicznego wzorca przepływu pracy (np. Bind (haskell) /callcc/Tasks.ContinueWith/F#'s async)
  • Użyj teorii kolejkowania, aby obliczyć, gdzie mogą wystąpić wąskie gardła
  • Używaj aktualizacji push-pull zamiast pull-read-modeli i innych stanów aplikacji. Np. Przez RabbitMQ / nServiceBus
  • Użyj najmniejszej funkcji „procedury obsługi http”
  • W przypadku plików statycznych podaj e-tagi i zasady wygasania pamięci podręcznej, aby umożliwić infrastrukturę sieciową działanie tak, jak powinno (np. Z kałamarnicą proxy)
  • (Zatrudnij mnie, aby rozwiązać problemy ze skalowaniem i uzyskać samouczki na miejscu;))
Henrik
źródło
4

Udostępnij architekturę Nic.

Mając to na uwadze i wbrew pozorom, nie od razu przejdź do rozwiązania skalowalnego w poziomie. Narzut poza systemem a wywołanie wewnątrz systemu nie powinny być niedoważone. Na przykład nawiązanie połączenia DB w dowolnym interfejsie sieciowym trwa dużo dłużej niż w przypadku połączenia lokalnego. Budżetuj ile czasu potrzeba na zarządzanie, zasilanie i strojenie potrzebne do skalowania w stosunku do dodatkowych $ za prawdziwy duży system.

Niezależnie od tego, nadal mam wielką wartość w architekturze „nic nie udostępniaj” i możesz warstwować i skalować swoje systemy, gdy przyjdzie czas.

Jé Queue
źródło
0

Równoległe żądania z kilku nazw hostów

Część standardu HTTP to sekcja, która mówi, że webclients zażądają maksymalnie 2 sesji na hosta DNS. Oto rozwiązanie, w którym ty i twój alias twoja www.domain.com otrzymujesz wyższą współbieżność żądań, dzięki czemu Twoja strona ładuje się szybciej:

/programming/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

Zasadniczo wymaga edycji programu obsługi HTTP ASP.NET na przemian z hostami docelowymi, do których wysyłasz klientów, gdzie każdy host to CNAME na „www”.

goodguys_activate
źródło
1
Ta odpowiedź ma więcej wspólnego z wydajnością po stronie klienta i nie ma nic wspólnego ze skalowaniem po stronie serwera.
Ken Liu,
Myślałem bardziej o linii środkowej, agregującej inne źródła danych przez HTTP. Tabela Azure, OData to tylko kilka przykładów ... Nadal jednak to serwer mówi przeglądarce (javascript), co ma robić.
goodguys_activate 18.09.11
0

Bezpieczny, szybki, niezawodny DNS

Znalazłem kilka witryn o dużej pojemności, korzystających z serwera DNS rejestratora, który nie miał SLA na czas działania ani wydajność. Ponadto ich serwery znajdowały się w Indiach, a samo opóźnienie zwiększa ryzyko, że spoofer DNS może zatruć pamięć podręczną klienta lub pośredniego dostawcę usług internetowych. Spowodowałoby to przekierowanie nawet twojego ruchu chronionego SSL bez wiedzy.

Szybkość DNS wpływa również na początkowy czas ładowania serwera, zanim rekordy zostaną buforowane.

Używam DynDNS lub Neustar do większości moich klientów, ponieważ mają dość solidną infrastrukturę DNS (chociaż jest to droga i nie mam innych powiązań z tymi firmami).

goodguys_activate
źródło
2
Err ... czy DNS naprawdę jest dla ciebie poważnym wąskim gardłem? Myślę, że to jedna z ostatnich rzeczy, które należy zoptymalizować.
Fishtoaster,
@Fishtoaster - Właśnie edytowałem pogrubioną część. Jestem pierwotnie Sysadminem, a bezpieczeństwo DNS odgrywa dużą rolę w sprawdzaniu poprawności SSL. Pojawiają się problemy z łącznością i wydajnością DNS, takie jak: problemy z routingiem BGP do SOA, problemy z Anycasting (dla CDN), problemy z opóźnieniami, zatruwanie pamięci podręcznej i inne. Napisałem narzędzie do sprawdzania najlepszych praktyk DNS (poziom drutu), które wkrótce wprowadzę do Internetu. Wypróbuj go, ponieważ obejmuje wiele problemów z łącznością, o których wspomniałem. (lub napisz do mnie e-maila, a wyjaśnię więcej)
goodguys_activate
2
Nie twierdzę, że nie ma problemów z wydajnością związanych z DNS, takich jak te, które wymieniasz. Wydaje mi się, że pojawiłyby się o wiele bardziej podstawowe problemy (dostęp do bazy danych, buforowanie strony, prosta złożoność zapętlania kodu, równoważenie obciążenia procesu serwera, wybór punktu dystrybucji sprzętu itp.) I byłyby rozwiązywane na kilku rzędach wielkości podczas skalowania przed DNS problemami byłyby problemy.
Fishtoaster
... Całkowicie się zgadzam, że są ważniejsze rzeczy do zmartwienia, tak jak wspomniałeś. Być może dlatego ten pomysł ma ocenę zerową :) .. ale z drugiej strony jestem jedyną, która jak dotąd odpowiedziała na to pytanie.
goodguys_activate
1
Wydajność DNS może z pewnością stanowić ogromne wąskie gardło - różnica między dobrem a złem może nie być duża, ale ponieważ DNS trafia przy każdym połączeniu (lub prawie każdym połączeniu), może naprawdę szybko zsumować. Zwłaszcza, gdy wchodzisz w nowoczesne akrobacje CDN.
Wyatt Barnett
0

Myślę, że klucz będzie prosty:

Mieć prosty kod. To oznacza coś, na co patrzysz i rozumiesz. Rozwijając i zmieniając serwery, musisz wiedzieć, co się dzieje. Konieczne może być także dodanie koderów, którzy muszą szybko zrozumieć. Haki i pliki XML, które wywołują losowy kod, który nie jest oczywisty, są bardzo złe.

Następnie możesz przetestować i znaleźć problemy.

Zajrzyj tutaj: http://blog.servint.net/2013/08/27/going-big-how-to-scale-a-website-part-1-infrastructure-that-scales/

W Stellarbuild staramy się, aby nasze strony skalowały się bez przestojów. Oznacza to, że musisz wiedzieć, co robi Twój kod i gdzie to robi. Nawet jeśli testujesz inną maszynę, skalowanie nie może zająć zbyt długo. Niestety większość ludzi zaczyna dopiero wtedy, gdy jest już za późno. Moim zdaniem możesz zoptymalizować tylko raz, gdy to zrobisz.

msj121
źródło