Przyjrzyj się, jak sprawdziliśmy nasz hosting w porównaniu z największymi hostami WordPress w Internecie.
To, co zaczęło się jako proste wewnętrzne ćwiczenie, aby zobaczyć, jak mierzył się nasz hosting, szybko przekształciło się w fascynującą podróż samopoznania.
Podróż, którą postanowiliśmy podzielić się z wami, drodzy czytelnicy bloga.
W końcu Szczycimy się uczciwością i uczciwością w tych częściach. A kiedy zdecydowaliśmy, że zabierzemy Was na przejażdżkę – jeden z głównych celów (oprócz kopnięcia**!) miał być całkowicie otwarty i przejrzysty. Zarówno z opublikowanymi wynikami, jak i naszymi metodami testowania.
W ten sposób można ufać, że wszystko jest legalne i nic nie zostało kołysane na naszą korzyść (co nikomu nie przynosi korzyści BTW).
To jest to, co dostajesz w tym artykule.
Wewnętrzne spojrzenie na to, jak jeden z naszych wewnętrznych ekspertów przetestował hosting WPMU DEV na najpopularniejszych platformach w branży.
Podążaj za tym i możesz odtworzyć naszą metodologię dla siebie.
* BTW, wszystkie narzędzia wymienione w tym artykule są CAŁKOWICIE DARMOWE!
Oto jak to wszystko się potoczyło…
Pierwszym krokiem było oczywiście utworzenie kont z dostawcami hostingu, z którymi chcieliśmy zmierzyć się WPMU DEV.
Mówiąc o, oto dzielni dostawcy hostingu DEV walczyli w tym porównaniu:
Wybraliśmy tych dziewięciu hostów, zarówno dlatego, że są to po prostu jedne z największych nazwisk w hostingu WP, jak i dlatego, że są to platformy, które zawsze wydają się być na językach naszych członków w rozmowach i ankietach.
Jesteśmy również świadomi, że bez względu na to, z kim zdecydujemy się porównać WPMU DEV, nie będzie zadowolenia wszystkich. Więc jeśli macie jakieś sugestie co do hostów, które powinniśmy porównać z DEV w przyszłości, dajcie nam znać, a my postaramy się jak najlepiej uwzględnić je w naszej następnej rundzie testów.
Moving on…
Aby testy były jak najbardziej sprawiedliwe, porównaliśmy plany poziomu podstawowego każdego dostawcy hostingu.
Użyliśmy również tej samej podstawowej strony testowej i dodaliśmy ją do każdego planu hostingowego.
Oto rzut oka na stronę testową, z której korzystaliśmy (miłośnicy psów przygotowują się do”awwww”):
Przetestowaliśmy każdego hosta z tym prostym (i cholernie uroczym!) pet website.
Czas na testowanie [hosta]!
Teraz zabawna część.
Po ustaleniu podstawowych (i uczciwych) punktów porównawczych nadszedł czas, aby rozpocząć proces testowania.
Chcieliśmy zobaczyć, jak każdy serwer hostingowy działa pod presją. W końcu ostatnią rzeczą, jakiej chcesz, jest awaria serwera, jeśli masz nagły napływ odwiedzających.
Chcieliśmy również przetestować szybkość każdego hosta, ponieważ ważne jest, aby obsługiwać klientów w odpowiednim czasie, w przeciwnym razie mogą się sfrustrować i kliknąć.
Przeprowadziliśmy więc dwa podstawowe testy wydajności na każdym hoście:
- Test obciążenia hostingu.
- Test prędkości (ttfb).
Oto jak przebiegały oba testy, zaczynając od testu obciążenia hostingu:
Testowanie, ilu równoległych użytkowników może obsłużyć każdy serwer hostingowy.
Do tego testu obciążenia użyliśmy “https://loader.io /” bezpłatna usługa testowania obciążenia, która allomożesz przetestować swoje aplikacje internetowe i interfejsy API za pomocą tysięcy jednoczesnych połączeń.
Loader.io pozwala na przeprowadzenie trzech różnych rodzajów testów:
1.”Klienci na test – – określasz całkowitą liczbę klientów do połączenia w czasie trwania testu.
2.”Klienci na sekundę ” – podobnie jak” klienci na test”, ale zamiast określać sumę, określasz liczbę klientów, którzy mają rozpocząć każdą sekundę.
3.”Utrzymuj obciążenie klienta” – ten test pozwala na określenie wartości a od I A do dla klientów.
Ponieważ chcieliśmy przetestować, jak każdy serwer hostingowy poradził sobie pod presją użytkowników – zdecydowaliśmy się uruchomić test “utrzymuj obciążenie klienta”.
Jak wspomniano, ten test działa poprzez umożliwienie określenia wartości od I do.
Oznacza to, że jeśli podasz na przykład “0” i “2000”, test rozpocznie się od 0 klientów i zwiększy się do 2000 jednoczesnych klientów na koniec.
Ustawianie granic testu obciążenia klienta.
Podczas uruchamiania każdego testu obciążenia ustawiamy maksymalny limit 5000 klientów. Okazało się, że jest to odpowiedni limit – ponieważ większość hostów i tak nie osiągnęła klientów 1000.
Wszystkie testy trwały 5 minut, a błąd został ustawiony na 1%, gdy tylko zaczęły pojawiać się błędy. Błędy te obejmują limity czasu, 400/500 i błędy sieciowe (wszystkie kumulują się do 1%).
Wybraliśmy 1% jako najniższą możliwą wartość, więc test natychmiast się zatrzyma i da najdokładniejszy odczyt max równoległych klientów.
Jest to ważne, ponieważ gdybyśmy na przykład mieli ustawienie fail na poziomie 50%, równoległe numery klientów byłyby znacznie wyższe, ale tylko dlatego, że dozwolona jest większa liczba użytkowników (z powodu wyższego ustawienia błędu).
Kiedy w rzeczywistości nie powinni się liczyć, ponieważ otrzymaliby odpowiedź błędu-co oznacza, że byli zasadniczo utraconymi gośćmi.
Pomiary, które wzięliśmy pod uwagę.
W tym konkretnym teście najbardziej zależało nam na” liczbie odpowiedzi “i metrykach” równoległych klientów”.
Liczba odpowiedzi pokazuje ogólny sukces / nieudane odpowiedzi:
Parallel Clients mierzy liczbę użytkowników, z którymi serwer może obsłużyć jednocześnie przed maksymalizacją:
Dlaczego liczba klientów równoległych obsługiwanych przez serwer jest ważna?
Zanim przejdziemy dalej rozwalmy nieco dalej tę ideę “równoległych klientów” …
Mówiąc prościej, max parallel clients to liczba osób, które mogą wysłać pierwsze żądanie HTTP do twojej witryny dokładnie w tym samym czasie.
Na przykład, powiedzmy, że maksymalna liczba równoległych klientów wynosiła 50. Oznacza to, że 50 osób może uzyskać dostęp do witryny dokładnie w tym samym czasie, zanim serwer ulegnie awarii.
Jeśli więc 60 osób spróbuje uzyskać dostęp w tym samym czasie, serwer uruchomi się ponownie i pokaże wewnętrzny błąd serwera przez następne kilka minut, podczas gdy zostanie ponownie uruchomiony – co oznacza, że stracisz odwiedzających
Oto dobra analogia, której lubimy używać:
“Jeśli wolisz mieć bar serwujący piwo 10 klientom, a następnie zamykający go, ponieważ 11-ty wzniecił pożar, w porządku.”
“Wolelibyśmy bar, który w odpowiednim czasie obsłuży 140 osób. Nawet jeśli jest trochę wolniej.”
Zasadniczo warto mieć hosta z wyższym równoległym numerem klienta (nawet jeśli czas reakcji jest nieco wolniejszy), ponieważ posiadanie mniejszej zdolności klienta równoległego naraża Cię na większe ryzyko awarii serwera i utraty odwiedzających.
Następnie testujemy szybkość każdego hosta.
Aby przetestować prędkość, użyliśmy narzędzia do testowania wydajności KeyCDN.
W skrócie, narzędzie testuje i mierzy wydajność dowolnego adresu URL z 10 różnych lokalizacji z całego świata.
Nie ma wiele do samego testu, po prostu wklej adres URL, który chcesz przetestować, i naciśnij przycisk. Pamiętaj, że jest również bezpłatny, więc możesz go używać do własnych testów.
Wyniki, które otrzymujesz, pokazują czasy ładowania i nagłówki odpowiedzi HTTP. Jak poniżej:
Patrząc na powyższą tabelę, metryką, którą najbardziej interesowaliśmy się w tym teście, była ” TTFB.”
TTFB mierzy czas od klienta wykonującego żądanie HTTP, do otrzymania pierwszego bajtu danych z serwera.
Duży problem z porównywaniem wyników TTFB…
Jedynym problemem jest to, że TTFB (lub szybkość hosta w ogóle) nie jest tak prosta do porównania. Dzieje się tak dlatego, że prędkość będzie się różnić w zależności od lokalizacji serwera hostów w stosunku do użytkownika.
Na przykład, jeśli serwer wybrany dla hostowanej witryny znajdował się w Holandii, odczyt TTFB z Amsterdamu zawsze będzie lepszy.
Tak więc, aby być uczciwym wobec wszystkich zaangażowanych gospodarzy, zdecydowaliśmy się zaprezentować odczyty TTFB na dwa różne sposoby:
- “Average TTFB” (Geo optimized) – był to najniższy (A. K. A best) odczyt TTFB spośród wszystkich testowanych lokalizacji.
- “Average ttfb” (we wszystkich lokalizacjach) – średni czas TTFB we wszystkich testowanych lokalizacjach.
Wyrównanie pola gry jeszcze bardziej.
Innym ważnym aspektem naszych testów jest fakt, że wszystkie testy były uruchamiane bez uwzględniania buforowania.
Zasadniczo oznacza to, że testowaliśmy same serwery hostingowe, a nie faktoring w żadnej pamięci podręcznej lub implementacje CDN każdy host może mieć. Zostało to zrobione przez zmuszenie WP do zalogowania się, więc wszystko jest pomijane.
Dlaczego uważamy, że lepiej jest testować bez włączonego buforowania (lub CDN).
Naszym zdaniem porównywanie pełnej wydajności pamięci podręcznej strony nie jest dobrym pomysłem w takiej sytuacji.
Wierzymy, że jest to prawda z kilku powodów:
- Omijanie pamięci podręcznej pozwala przetestować wydajność samych serwerów hostingowych. Jest to ważne, ponieważ oznacza, że nie musisz polegać na mechanizmach buforowania (więcej o tym, dlaczego jest to ważne poniżej).
- Testowanie z cache nie trwa “dynamic” działania strony pod uwagę.
Każda platforma hostingowa może umieścić CDN przed swoją witryną, powiedzieć mu, aby wszystko buforował, a następnie twierdzi, że zapewnia szalenie szybkie i skalowalne witryny.
Problem polega na tym, że zwykle nie jest to praktyczne w prawdziwym świecie jako WordPress, a wiele jego wtyczek ma być dynamicznych.
Na przykład buforowanie to świetny sposób na przyspieszenie prostych witryn lub stron. Jak “o stronie” – która rzadko się zmienia i w większości przypadków nie miałaby zbyt wielu akcji na żywo lub dynamicznych.
Porównaj to z pełnowymiarowym sklepem eCommerce, który stale wykonuje dynamiczne działania (proces kasowania na żywo itp.), które omijają pamięć podręczną i uderzają bezpośrednio w serwer.
Dlatego często słyszysz (lub doświadczasz) sklepów eCommerce mających problemy podczas dużych sprzedaży lub promocji. Ich serwery nie są przygotowane (lub nie zostały przetestowane!) i nie może obsługiwać wszystkich jednoczesnych dynamicznych działań.
Zasadniczo, twój przyjaciel Mr. Cache nie zawsze będzie tam, aby cię uratować, więc lepiej jest postrzegać to jako dodatkową korzyść i nadal mieć pewność, że twój serwer będzie w stanie poradzić sobie sam.
… Więc jak WPMU DEV radzi sobie z najpopularniejszymi hostami WordPress w Internecie?
Zawsze aktualizujemy powyższe, więc spodziewaj się naszych najbardziej aktualnych wyników testów.
Byłbym również niedbały, gdybym nie zaprosił cię do sprawdzenia naszych planów hostingowych lub przyjęcia członkostwa WPMU DEV (w tym. 1 Bronze level hosted site) NA darmowy 7-dniowy okres próbny.
W ten sposób możesz zobaczyć, jak nasz hosting działa dla siebie i przeprowadzić własne testy zgodnie z naszą metodologią (lub dowolną inną preferowaną przez Ciebie).