50
Za wieloma decyzjami dotyczącymi hostingu kryje się ciche założenie: wystarczy wybrać odpowiednią moc procesora i pamięć RAM, a serwer będzie działał szybko. Jeśli chodzi o samą moc obliczeniową, to prawda. Jednak w odniesieniu do tego, jak szybko usługa wydaje się działać dla osoby z niej korzystającej, często tak nie jest. W dużej mierze zależy to od czynnika, którego nie da się rozwiązać żadną modernizacją: od fizycznej odległości serwera od użytkowników.
Chodzi o opóźnienie, o którym warto wiedzieć przed wyborem dostawcy usług hostingowych.
Odległość to czas, a fizyka wyznacza dolną granicę
Dane nie przemieszczają się natychmiastowo. Przemieszczają się one przez światłowód w postaci światła, a światło w szkle porusza się z prędkością wynoszącą około dwóch trzecich prędkości światła w próżni, czyli około 200 000 km na sekundę. Brzmi to na tyle szybko, że można to zignorować, dopóki nie przypomnimy sobie, że sygnał musi dotrzeć tam i wrócić z powrotem przy każdym żądaniu.
Podróż w obie strony między pobliskimi miastami może zająć zaledwie kilka milisekund. Trasy długodystansowe i międzykontynentalne mogą wydłużyć opóźnienie w obie strony do kilkudziesięciu, a nawet kilkuset milisekund, w zależności od lokalizacji i ścieżki sieciowej. Nie zmieni tego żaden szybszy procesor. Nie da się obliczyć drogi pozwalającej na przekroczenie prędkości światła.
Gdzie faktycznie to odczuwamy
Dodatkowe 80 ms przy pojedynczym żądaniu może być niezauważalne. Problem polega na tym, że nowoczesne aplikacje rzadko wysyłają tylko jedno żądanie.
Załadowanie jednej strony może oznaczać dziesiątki cykli: najpierw kod HTML, potem zasoby, do których się odwołuje, następnie wywołania API, a na końcu zapytania do bazy danych. Każde z nich ponosi „opłatę za odległość”. Po zsumowaniu tych opóźnień strona obsługiwana z niewłaściwego kontynentu wydaje się działać tak wolno, że żadna moc serwera nie jest w stanie tego wyjaśnić.
Dla kogo ma to największe znaczenie
Nie każde obciążenie jest wrażliwe na opóźnienia, więc warto szczerze określić, kto powinien się tym przejmować.
Najpierw odczuwają to usługi działające w czasie rzeczywistym i interaktywne. Gry online, rozmowy wideo, narzędzia do współpracy na żywo, platformy transakcyjne – wszystko, gdzie człowiek czeka na odpowiedź w danej chwili. Tutaj dziesiątki milisekund stanowią różnicę między płynnym działaniem a frustracją.
Kolejną grupą są interaktywne aplikacje internetowe i interfejsy API. Pulpit nawigacyjny, który wysyła wiele małych żądań, lub interfejs API, do którego inne systemy zwracają się sekwencyjnie, zwielokrotnia wpływ każdej milisekundy odległości.
Najmniej ma to znaczenie w przypadku zadań masowych i wykonywanych w tle. Jeśli za pośrednictwem sieci CDN uruchamiasz zadania wsadowe, tworzenie kopii zapasowych lub obsługujesz w większości statyczną stronę internetową, fizyczna lokalizacja ma znacznie mniejsze znaczenie.
Czego nie rozwiązuje lokalizacja, a co zapewnia CDN
Sieć CDN pomaga, ale warto znać jej ograniczenia. Sieć dostarczania treści buforuje pliki statyczne blisko użytkowników, dzięki czemu obrazy, skrypty i arkusze stylów docierają szybko z pobliskiego węzła brzegowego. To realna i przydatna korzyść.
To, czego sieć CDN nie przybliża, to rzeczywista logika aplikacji i baza danych. Części dynamiczne, te, które podejmują decyzje i odczytują dane, nadal działają tam, gdzie znajduje się serwer. W przypadku aplikacji dynamicznej lokalizacja źródłowa nadal wykonuje większość pracy, na którą czeka użytkownik.
Wybór lokalizacji w praktyce
Zasada jest prosta: umieść serwer blisko osób, które najczęściej z niego korzystają. Jeśli Twoi odbiorcy znajdują się głównie w Europie, europejskie centrum danych zazwyczaj zapewni mniejsze opóźnienie sieciowe niż serwer położony po drugiej stronie oceanu. Sprzęt nadal ma znaczenie, ale nie jest w stanie zniwelować fizycznej odległości między serwerem a użytkownikiem.
Gdy użytkownicy są rozproszeni po różnych regionach, szczera odpowiedź brzmi: żadna pojedyncza lokalizacja nie jest idealna. Należy wybrać lokalizację najbliższą największej lub najbardziej wrażliwej na opóźnienia grupie użytkowników, a do obsługi warstwy statycznej wykorzystać sieć CDN, aby złagodzić problemy w pozostałych obszarach.
INTROSERV oferuje serwery w Europie, Ameryce Północnej, Azji i Australii, w takich lokalizacjach jak Frankfurt, Londyn, Amsterdam, Naaldwijk, Beauharnois (Kanada), Singapur i Sydney, co daje więcej możliwości umieszczenia infrastruktury bliżej użytkowników.
Wniosek
Lokalizacja nie jest szczegółem, który optymalizuje się na końcu. W przypadku wszelkich aplikacji interaktywnych stanowi ona podstawę, na której opierają się wszystkie pozostałe optymalizacje. Dobrze dobrana lokalizacja może mieć większy wpływ na aplikację interaktywną niż modernizacja sprzętu, która nie zmienia ścieżki sieciowej.
Zanim zaczniesz porównywać procesory, zadaj sobie najpierw prostsze pytanie: gdzie znajdują się moi użytkownicy i jak daleko od nich znajduje się serwer?
