Hosting współdzielony: kiedy szybkie procesory są pomocne mimo niewielkiej liczby rdzeni

Różnica między jądrem, wątkami i czasem procesora

Rdzeń fizyczny to jednostka obliczeniowa procesora. Natomiast system operacyjny postrzega go jako procesory logiczne jako jednostki wykonawcze: w przypadku jednoczesnego wielowątkowości kilka z nich może współdzielić zasoby jednego rdzenia fizycznego. Ich liczba nie pozwala zatem bezpośrednio określić, ile niezależnych od siebie rdzeni jest dostępnych dla danego konta hostingowego.

W ramach hostingu współdzielonego kilka kont korzysta wspólnie ze sprzętu serwera. Pakiet taryfowy może określać, ile czasu procesora mogą zużywać procesy danego konta w danym okresie. To Budżet czasu procesora to coś innego niż zobowiązanie do wyłącznego korzystania z fizycznego jądra. Grupy cgroups w systemie Linux stanowią jedną z możliwych podstaw technicznych dla takich ograniczeń, ale nie są jedyną możliwą realizacją.

Jeśli w taryfie widnieje np. „jeden vCore“ lub „100 procent mocy procesora“, należy sprawdzić definicję podaną przez dostawcę. Informacja ta może odnosić się do limitu czasu obliczeniowego bez stałej rezerwacji konkretnego rdzenia. Również z całkowitej liczby rdzeni serwera hosta nie wynika, jaką moc obliczeniową pojedyncze konto może faktycznie wykorzystywać jednocześnie.

W tym kontekście równoczesność oznacza, ile zapytań lub procesów może być przetwarzanych równolegle. Zależy to między innymi od limitów procesów, pamięci i dostępnego budżetu procesora. CloudLinux może w tym celu stosować własne limity zasobów; aby dowiedzieć się, czy dany plan taryfowy korzysta z tej technologii i jak jest skonfigurowana, należy skontaktować się z dostawcą.

Ograniczenie zasobów i izolacja bezpieczeństwa spełniają różne zadania: limit reguluje zużycie, natomiast izolacja ma na celu ograniczenie dostępu między środowiskami. Te Omówienie funkcji CloudLinux Site Isolation i CageFS wyjaśnia odpowiednie mechanizmy bezpieczeństwa; samo w sobie nie pociąga to za sobą konkretnego przydziału procesora.

Dlaczego sama częstotliwość w GHz nie jest decydująca

Częstotliwość taktowania określa, ile cykli taktowych procesor wykonuje na sekundę. Wyższa częstotliwość taktowania może przyspieszyć operacje zależne od procesora, ale sama w sobie nie określa, w jakim stopniu strona internetowa z tego korzysta. Różne architektury procesorów wykonują różną ilość pracy na jeden takt; na wynik wpływa również konkretny kod programu.

Do Wydajność jednonukleowa Dodatkowo wpływ mają pamięć podręczna i sposób wykorzystania pamięci. Jeśli proces musi często czekać na dane, wyższa częstotliwość może przynieść mniejsze korzyści niż w przypadku obliczeń, w których dane są już szybko dostępne. Porównanie oparte wyłącznie na GHz pomija te różnice i nie zastępuje testów wydajnościowych dostosowanych do konkretnych zastosowań.

Przykładem ograniczonej specyfikacji technicznej jest procesor AMD EPYC 4564P: w przypadku tego modelu firma AMD podaje 16 rdzeni, 32 wątki, częstotliwość bazową 4,5 GHz oraz maksymalną częstotliwość w trybie Boost wynoszącą do 5,7 GHz. Dane te opisują sam procesor, a nie wydajność konkretnego pakietu hostingowego.

Der Maksymalne wzmocnienie nie jest to ani gwarantowana stała wartość, ani częstotliwość występująca w dowolnym momencie na wszystkich rdzeniach. Dane produktowe nie wskazują również, jak szybko dana taryfa hostingu współdzielonego przetwarza zapytanie WordPressa lub PHP. Oprócz sprzętu wpływ na to mają również konfiguracja, obciążenie oraz limity taryfowe.

Jeśli dostawcy z hosting procesorów o wysokiej częstotliwości W związku z tym zapytaj o konkretny model procesora i dostępny budżet na zasoby. Aby porównania wydajności były miarodajne, potrzebne są dodatkowo informacje dotyczące wersji oprogramowania, konfiguracji serwera, obciążenia oraz warunków testowych. Bez tych danych nie da się wiarygodnie przełożyć reklamowanej wartości GHz na krótszy czas odpowiedzi.

Zapytania PHP i przetwarzanie równoległe

W przypadku typowego żądania synchronicznego proces roboczy PHP przetwarza poszczególne etapy swojej pracy głównie jeden po drugim. Szybszy procesor może skrócić tę część, jeśli faktycznie wymaga ona intensywnych obliczeń. Jeśli natomiast procesor czeka głównie na odpowiedź z bazy danych lub usługi zewnętrznej, korzyści wynikające z większej mocy obliczeniowej procesora w odniesieniu do tego czasu oczekiwania są ograniczone.

Sformułowanie zapytania php jednordzeniowy Nie oznacza to jednak, że cała strona internetowa może korzystać tylko z jednego jądra. Kilka żądań może być przetwarzanych równolegle przez kilka procesów roboczych; również serwer WWW i baza danych mogą działać jednocześnie. Decydujące znaczenie ma to, na jaki zakres tej równoległej pracy pozwalają dostępne zasoby i dana konfiguracja.

W przypadku PHP-FPM ograniczenie wynosi pm.max_children liczba żądań obsługiwanych jednocześnie przez pulę. Po osiągnięciu tego limitu kolejne żądania nie mogą być natychmiast przetwarzane przez kolejnego pracownika tej puli. Limit ten nie określa jednak, ilu użytkowników łącznie może korzystać ze strony internetowej.

Die Zarządzanie procesami PHP-FPM obsługuje trzy tryby pracy: static utrzymuje stałą liczbę procesów roboczych. dynamic dostosowuje ich liczbę do popytu na podstawie konfiguracji; ondemand uruchamia procesy w razie potrzeby. Wybrany tryb pracy decyduje zatem również o tym, kiedy procesy są gotowe do działania lub kiedy są uruchamiane na nowo.

Większa liczba procesów nie oznacza automatycznie dłuższego czasu procesora. Procesy te wymagają również pamięci operacyjnej i mogą wspólnie osiągnąć limit konta w przypadku wykonywania równoległego. Aby ocenić współdzielony hosting – procesor Dlatego liczba procesów roboczych i budżet zasobów są ze sobą powiązane. Nie każdy plan taryfowy korzysta z PHP-FPM ani nie pozwala klientom samodzielnie zmieniać jego ustawień.

Limit procesora przy obciążeniu równoległym

A Limit procesora określa, ile czasu obliczeniowego może zużyć grupa procesów w danym przedziale czasowym. W systemie Linux cgroup v2 opisuje cpu.max ten budżet i odpowiadający mu okres. Kwota ta nie rezerwuje zatem automatycznie wyłącznego rdzenia fizycznego: ogranicza ona całkowity dostępny czas procesora dla tej grupy.

Przykład obliczeniowy o charakterze ilustracyjnym, nie jest to pomiar: pewna grupa otrzymuje 100 milisekund czasu procesora na każdy okres trwający 100 milisekund. Odpowiada to średniemu czasowi obliczeniowemu w pełni obciążonego procesora logicznego. Jeśli dwa procesy wykonują obliczenia jednocześnie na dwóch dostępnych procesorach logicznych, teoretycznie mogą wyczerpać wspólny limit po około 50 milisekundach czasu rzeczywistego.

Jeśli budżet zostanie wyczerpany, procesy mogą zostać spowolnione do następnego okresu. Oba procesy robocze nie dysponują zatem osobnym budżetem wynoszącym 100 milisekund. To, czy i kiedy faktycznie będą działać równolegle, zależy między innymi od harmonogramu, dostępnych procesorów i ich zachowania; przykład ten nie przewiduje konkretnego czasu odpowiedzi.

Na potrzeby badania cgroup v2 w cpu.stat między innymi liczniki do Dławienie gotowe. Jeśli wzrosną podczas reprezentatywnej fazy obciążenia, oznacza to, że limit został wyczerpany. Pojedynczy odczyt licznika nie wyjaśnia jednak, które zapytanie było przyczyną tego stanu rzeczy ani czy występują również inne wąskie gardła.

To, czy pliki te są dostępne w ramach pakietu i mają znaczenie dla strony internetowej, musisz ustalić z dostawcą. Hosting współdzielony może wykorzystywać inne mechanizmy: na przykład CloudLinux dokumentuje własne limity LVE dla procesora i innych zasobów. Na podstawie przykładu z systemem Linux nie można zatem wywnioskować ani konkretnej konfiguracji, ani zachowania każdego konta hostingowego.

CMS, sklep internetowy i zadania działające w tle

W przypadku strony CMS bez pamięci podręcznej serwer wykonuje logikę aplikacji w odpowiedzi na żądanie i pobiera niezbędne dane. Jeśli znaczna część przetwarzania sprowadza się do Praca procesora, większa wydajność na rdzeń może skrócić ten etap. Dotyczy to na przykład skomplikowanych obliczeń w kodzie PHP, ale niekoniecznie całego czasu potrzebnego do wygenerowania gotowej strony.

Jeśli natomiast to samo żądanie polega głównie na zapytaniu do bazy danych lub korzystaniu z zewnętrznego API, proces PHP może w tym czasie tylko w ograniczonym stopniu skorzystać z szybszego procesora. Dlatego przy podejmowaniu decyzji liczy się podział czasu odpowiedzi po stronie serwera: ile czasu zajmują obliczenia, a ile – oczekiwanie na inne usługi?

Jeden sklep pokazuje, dlaczego odpowiedź na to pytanie może się różnić w zależności od strony. Publiczne strony produktów można, pod odpowiednimi warunkami, zapisać w pamięci podręcznej jako gotową odpowiedź. Jeden Trafienie w pamięci podręcznej może zapobiec ponownemu pełnemu przetwarzaniu kodu PHP; koszyk i proces realizacji zamówienia muszą natomiast często uwzględniać indywidualne dane i pozostają dynamiczne.

Wiele jednoczesnych żądań realizacji transakcji może zatem obciążać procesy robocze lub zasoby procesora bardziej niż taka sama liczba wywołań stron z pamięci podręcznej. Sama liczba odwiedzających nie oddaje w pełni tego obciążenia: decydujące znaczenie ma to, do których punktów końcowych kierowane są jednoczesne żądania oraz jak często wykorzystywana jest pamięć podręczna. W przypadku PHP-FPM ograniczeniem jest ponadto ustawienie puli pm.max_children liczba żądań obsługiwanych jednocześnie.

Import danych wymagający dużej mocy obliczeniowej w zapleczu może z kolei skorzystać na szybszej pracy pojedynczych procesów. Jeśli przebiega on równolegle z żądaniami użytkowników, procesy te mogą konkurować o ten sam limit czasu procesora. To, czy zadanie cronowe lub import są faktycznie przypisane do tej samej ograniczonej grupy, zależy od planu taryfowego i jego konfiguracji; przed podjęciem decyzji dotyczącej wydajności skontaktuj się z dostawcą.

Aby uzyskać miarodajne porównanie, należy rozpatrywać te obciążenia osobno: typowe zapytanie dynamiczne, fazę z wieloma równoczesnymi zapytaniami oraz, w razie potrzeby, import podczas bieżącej pracy systemu. W ten sposób łatwiej zorientujesz się, czy ważniejszym czynnikiem jest szybkość pojedynczego etapu pracy, czy też całkowita dostępna wydajność.

Porównanie obserwacji i wąskich gardeł

Powolna odpowiedź nie oznacza jeszcze, że znamy jej przyczynę. Poniższe zestawienie łączy typowe obserwacje z możliwymi do sprawdzenia przyczynami. Uwzględnia ono w szczególności limity czasu procesora, ograniczoną liczbę procesów roboczych w PHP-FPM oraz różnicę między zapisanym kodem PHP a już wygenerowaną odpowiedzią.

Każdy wiersz tabeli to Hipoteza, a nie gotową diagnozę. Powolne odpowiedzi w warunkach równoległości mogą na przykład wynikać z ograniczenia wydajności procesora, ale mogą też być spowodowane zajętością procesów roboczych lub oczekiwaniem na odpowiedź bazy danych. Dlatego w miarę możliwości sprawdzaj kilka sygnałów jednocześnie dla tego samego obciążenia, zamiast wyciągać wnioski o zmianie taryfy na podstawie pojedynczego objawu.

Podczas analizy rozróżnij Czas reakcji W przypadku zapytań dotyczących przepustowości: szybsza pojedyncza odpowiedź nie oznacza automatycznie, że przy wysokim stopniu współbieżności przetwarzanych będzie odpowiednio więcej zapytań na sekundę. Z drugiej strony system może osiągać dobrą przepustowość, a mimo to poszczególne zapytania mogą czekać dłużej.

Również postrzegany czas ładowania strony nie jest równoznaczny z czasem odpowiedzi po stronie serwera. Po otrzymaniu odpowiedzi mogą na przykład zostać załadowane i przetworzone w przeglądarce dodatkowe zasoby. Modernizacja procesora w ramach hostingu dotyczy wyłącznie odpowiedniej części po stronie serwera; aby zapewnić rzetelne porównanie, stan pamięci podręcznej, żądana strona oraz równoległość przetwarzania powinny pozostać niezmienne.

W przypadku pamięci podręcznej warto również rozróżnić pojęcia: OPcache przechowuje skompilowany kod PHP, dzięki czemu pozwala uniknąć ponownej kompilacji. Natomiast pamięć podręczna stron przechowuje wygenerowaną odpowiedź. Szybkie trafienie w pamięci podręcznej nie oznacza zatem ani tego, że dynamiczne zapytania mają wystarczające zasoby procesora, ani tego, że OPcache zastępuje logikę aplikacji.

Rozpoznawanie ograniczeń przepustowości i czasów oczekiwania

Rozpocznij diagnostykę od zapytań typowych dla Twojej witryny: na przykład od publicznej strony CMS, wyszukiwania, a w przypadku sklepu – od procesu realizacji zamówienia. Sprawdź, czy dana odpowiedź pochodzi z pamięci podręcznej strony. Następnie porównaj pojedyncze wywołania oraz liczbę jednoczesnych zapytań reprezentatywną dla Twojego projektu, zamiast skupiać się wyłącznie na ogólnej liczbie odwiedzających.

W miarę możliwości oddziel czas procesora na całkowity czas odpowiedzi oraz czasy oczekiwania na dane z bazy danych lub usług zewnętrznych. Jeśli udział procesora jest niewielki, szybszy procesor może skrócić jedynie odpowiednio ograniczoną część wywołania. Jeśli nie dysponujesz odpowiednimi danymi pomiarowymi, poproś dostawcę o udostępnienie logów, wskaźników lub odpowiedniej analizy.

W przypadku obciążenia równoległego sprawdź, czy dostępne procesy robocze są w pełni obciążone i czy liczniki limitów rosną. W przypadku PHP-FPM ograniczenie wynosi pm.max_children liczbę żądań obsługiwanych jednocześnie przez pulę; to, czy możesz zobaczyć tę wartość lub obciążenie, zależy od planu taryfowego. Systemy z cgroup v2 w Linuksie mogą w cpu.stat w tym wskaźniki dławienia. Rosnąca wartość wskaźnika stanowi powód do dokładniejszego sprawdzenia budżetu procesora oraz okresu pomiarowego.

Jeśli SSH i dany plik są dostępne, wyświetli się cat /proc/self/cgroup przypisanie do grupy cgroup procesu wywołującego. Nie oznacza to jednak, że żądania internetowe są przetwarzane w tej samej grupie. Należy uzgodnić ścieżki, uprawnienia i sposób interpretacji z dostawcą; również kodów błędów nie da się ogólnie przypisać do konkretnego limitu obowiązującego w każdym systemie hostingu współdzielonego.

Sprawdź pamięć podręczną i porównaj taryfy

Najpierw sprawdź, które strony publiczne można bezpiecznie zapisać w pamięci podręcznej jako pełną odpowiedź. Jedna Pamięć podręczna stron może zapobiec wielokrotnemu przetwarzaniu dynamicznego w przypadku trafienia. Z kolei spersonalizowane treści, koszyk i proces realizacji zamówienia wymagają odpowiedniej strategii buforowania, aby odwiedzający nie otrzymywali obcych lub nieaktualnych danych.

Innym podejściem jest zmniejszenie obciążenia w przypadku nieudanych odwołań do pamięci podręcznej: przeanalizuj powolne zapytania do bazy danych i wyeliminuj zbędne przetwarzanie dynamiczne. W przypadku usługi zewnętrznej decydujące znaczenie może mieć czas jej odpowiedzi; w takiej sytuacji należy najpierw przyjrzeć się temu wywołaniu, zamiast zakładać, że przyczyną jest obciążenie procesora. To, która zmiana okaże się pomocna, zależy od faktycznie powolnej ścieżki.

Należy to odróżnić od OPcache: Przechowuje skompilowany kod PHP, ale nie zastępuje ani pełnej pamięci podręcznej stron, ani wykonywania logiki aplikacji. Sprawdź dostępność i ustawienia w środowisku uruchomieniowym serwisu. CLI posiada własne ustawienie OPcache; samo sprawdzenie wiersza poleceń nie potwierdza zatem konfiguracji dla żądań internetowych.

Aby porównać taryfy, należy zestawić te same zapytania przy użyciu identycznych wersji oprogramowania, porównywalnych zbiorów danych oraz zarejestrowanego stanu pamięci podręcznej. Powtórz porównanie przy tej samej równoległości i uwzględnij dostępne w danym momencie zasoby procesora, procesów roboczych oraz pamięci. W przeciwnym razie różnice mogą wynikać z warunków testowych, nie dostarczając przy tym wiarygodnych informacji na temat wydajności procesora.

Ponadto należy oddzielnie odnotować, ile czasu zajmuje udzielenie poszczególnych odpowiedzi oraz ile zapytań jest przetwarzanych w danym okresie. Taryfa może wydawać się korzystna w przypadku pojedynczego wywołania, ale przy jednoczesnym obciążeniu może mimo to osiągnąć swoje granice. Wyniki porównania mają początkowo zastosowanie wyłącznie do badanej aplikacji i jej warunków.

Szybszy procesor czy większy budżet?

Jeśli reprezentatywne zapytanie dynamiczne wykorzystuje głównie moc obliczeniową procesora, a ani liczba procesów roboczych, ani pamięć, ani budżet czasowy nie stanowią ograniczenia, wyższa Moc Pro-Kern realna opcja taryfowa. Może ona skrócić czas obliczeniowy poszczególnych zapytań. To, w jakim stopniu wpłynie to na całkowity czas odpowiedzi, nadal zależy jednak od aplikacji i jej czasów oczekiwania.

Jeśli natomiast dane wskazują na spowolnienie lub przeciążenie procesów roboczych w przypadku wielu jednoczesnych zapytań, sprawdź, czy nie warto zwiększyć Budżet zasobów. W przypadku wyczerpania limitu przydziału pomocne może być zwiększenie czasu procesora; dodatkowe procesy robocze wymagają jednocześnie wystarczającej ilości pamięci i czasu obliczeniowego. Jeśli wąskim gardłem jest baza danych lub usługi zewnętrzne, samo zwiększenie budżetu procesora nie stanowi niezawodnego rozwiązania.

Przed wprowadzeniem zmian warto porównać je z optymalizacją istniejącej instalacji. Odpowiednia pamięć podręczna stron lub ulepszone zapytania mogą ograniczyć obciążenie dynamiczne bez konieczności natychmiastowego przechodzenia na wyższy pakiet taryfowy. Po wprowadzeniu zmian powtórz diagnostykę w podobnych warunkach, aby móc odróżnić ich wpływ od innych czynników.

A VPS jako alternatywa dla hostingu współdzielonego Zazwyczaj zapewnia większą swobodę w zakresie oprogramowania i konfiguracji, ale wiąże się również z większą odpowiedzialnością za bezpieczeństwo, aktualizacje i planowanie wydajności. Wirtualne procesory nie są wyłącznymi rdzeniami fizycznymi, o ile dostawca nie zapewni tego wyraźnie. Dlatego należy sprawdzić konkretny przydział zasobów oraz warunki umowy.

Przed podjęciem decyzji zapytaj dostawcę o model procesora, definicję budżetu czasu procesora oraz sposób radzenia sobie ze szczytami obciążenia. Dowiedz się również, jakie obowiązują limity dotyczące procesów roboczych i pamięci, czy zadania w tle dzielą ten sam budżet oraz jakie liczniki limitów możesz sprawdzić. Dopiero te informacje pozwalają właściwie ocenić reklamowaną wydajność procesora w kontekście konkretnego planu taryfowego.