sebak

Niestety, dane zajmowały więcej niż ilość ramu na serwerze. Podniesione. Dzięki za informacje.

Nie chcę być upierdliwy, ale Hetzner ma jedną z gorszych wydajności jeśli chodzi o serwery VPS. W projekcie webspeed.pl testowałem cały szereg firm i ich rozwiązania (Hetzner) oferowały najmniejszą dostępną moc obliczeniową. Być może dlatego, że serwer fizyczny nie jest z gumy. Jeśli oferujesz tanie usługi bez nadzoru, to co z tego że w ofercie masz 1 lub 2 vCPU, skoro jako klient realnie masz dostęp do ~50% jednego fizycznego rdzenia, bo wszyscy biją się o fizyczne zasoby, a dysponują jedynie wirtualnymi. Porównujesz rzecz fizyczną z usługą współdzieloną, co jest totalnie bez sensu. Jak kupujesz serwer dedykowany, to zasoby masz tylko dla siebie. Jeśli kupujesz zasoby współdzielone, to chcesz by podział tych zasobów był realizowany na sprawiedliwych zasadach. Tak, byś mógł wykorzystać te zasoby, wtedy kiedy tego potrzebujesz i by klient obok, Cię nie spowalniał.

Dzięki za propozycję, ale obecnie chce by wszystkie serwery testujące stały w Polsce. Poniżej aktualna lista wszystkich adresów IP odpytujących o strony: 145.239.93.87 54.38.50.21 54.38.56.124 54.38.58.71 212.127.78.98 185.238.75.151 195.2.209.61 195.2.209.62 188.68.242.185 Adresy mogą się zmieniać z czasem.

@l3szcz dziękuję za udostępnienie serwera VPS pod projekt. Będzie odpytywał witryny jako checker-domains-8.webspeed.pl.

Jakieś 2 godzinki temu wysłałem odpowiedź .

Oczywiście, każda maszynka jest mile widziana .

@Mion każdy z wątków które dokonują sprawdzenia stoi w polskiej lokalizacji, tak by właśnie nie przekraczać 10-20 ms, który może wynikać z różnic w lokalizacjach.

Jeśli średni czas generowania strony Wordpress (index.php) to około 1500 ms, to jakiekolwiek odchylenia 20-30 ms między różnymi lokalizacjami w Polsce jest przy tym wyniku pomijalne. home.pl i az.pl nie blokuje narzędzia, tylko całą adresację z OVH, co za tym idzie i webspeed.pl na to wpadł.

@Tom X poszła wiadomość w tej sprawie na PW.

@Tom X jest to raczej standard w systemach typu status page. Wychodzimy z założenia, że usługi działają i chcemy w prosty sposób nanieść na oś czasu termin wystąpienia problemu. Uptime jest per każda strona, nie per hostingodawca. Zawsze priorytet ma kolor czerwony ;-).

@Tom X Słupki charakteryzują każdy dzień z ostatnich 30 dni. Jeśli wystąpiła niedostępność, czy timeout danego dnia, słupek za konkretny dzień zmienia swój kolor na czerwony, jeśli wystąpił błąd serwera (np. 500) mamy kolor pomarańczowy. Nie oznacza to, że strona tego dnia, była przez cały dzień niedostępna, ale że w danej dacie wystąpił problem. Szczegóły niedostępności masz po kliknięciu na przycisk pod wykresem.

Zmiana została zaimplementowana.

Jeśli pozycja w rankingu nie musi być aktualna, to mogę ją zamienić na średnią z doby poprzedzającej aktualną datę. Średnie dobowe i tak przeliczamy codziennie w godzinach nocnych, więc akurat na tą wartość mogę w prosty sposób podmienić ranking. Wtedy będzie miał dobowe opóźnienie, ale będzie bardziej stabilny emocjonalnie.

Średnia 10 dniowa nie istnieje nigdzie w naszej bazie danych, jest liczona w momencie serwowania strony. Co innego obliczyć średnią na bieżąco dla 1 strony, a co innego liczyć ją każdorazowo dla 2 mln domen. Zaś ranking redisowy działa na zasadzie przyporządkowania WARTOŚCI LICZBOWEJ do KLUCZA. W prosty sposób możesz pobrać pozycje z rankingu, ale musisz podać istniejący KLUCZ. W naszym przypadku KLUCZEM jest domena, a WARTOŚCIĄ LICZBOWĄ czas jej wczytywania wyrażony w ms.

@Tom X ostatni pomiar poszedł pewnie z jakiegoś cache. Całość działa na rankingach redisowych. Inaczej ciężko było by porównywać te wartości, przy tak dużej ilości domen. Ranking jest aktualizowany zawsze o ostatnią wartość która jest aktualnie pobrana przy sprawdzaniu czasu strony. Mam świadomość, że w takich sytuacjach jak ta, wygląda to "dziwnie", niemniej nie znalazłem żadnego sensownego rozwiązania tego problemu.