sebak

@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.

@Tom X specjalnie dla Ciebie wystartował .

@MAXX jesteś profesjonalistą podobno, więc potrafisz korzystać. czegoś takiego jak manual. Wskazałem Ci podpowiedź. Literki nie gryzą, naprawdę dla profesjonalisty nie powinien być to problem. Idąc Twoim tokiem rozumowania, masz za mało doświadczenia, więc jak je nabierzesz wróć proszę do tematu.

Oczywiście, gdybyś chociaż raz przeczytał i zagłębił się w metodologię testów, która jest dogłębnie opisana na https://webspeed.pl/about, wiele Twoich pytań i sugestii nie miało by miejsca. Ale oczywiście, łatwiej jest uważać się za profesjonalistę, ale do czegoś takiego jak "manual" projektu nawet nie zerknąć. Jeśli jesteś profesjonalistą, a to co prezentujemy Ci się nie podoba, zrób proszę coś lepszego, gdzie pokażesz swoje umiejętności i profesjonalizm. Bo w tej chwili trolujesz i atakujesz, zarzucasz brak doświadczenia, ale sam żadnym swoim profesjonalnym projektem pochwalić się nie możesz... Zachęcam przejrzeć metodologię pomiarów. Curl, chyba nie jest poleceniem zbyt trudnym w obsłudze dla takiego profesjonalisty, więc powinieneś zrozumieć...

Jeśli coś komuś zarzucasz, wyrzuć dowody, lub nie trolluj publicznie. Słabe jest zarzucanie czegoś, na podstawie widzimisię, bez grama dowodów lub chociażby elementarnej logiki. Więc zacznijmy od logiki. Jeśli byś kiedykolwiek czytał temat webspeed.pl na tym forum, to iTomek, był jedną z osób, które najmocniej krytykowały projekt. Logicznym jest też, że gdy zauważyli, że wypadają w nim dość dobrze, to zaczęli się tym chwalić. Idąc do samego wrapera sprawdzającego wielkość strony, to jest on niezależny od systemu sprawdzania czasów i ma mniejszy priorytet. Proces wykonuje się w przerwie między kolejnymi odpytywaniami o czas wczytywania strony. W związku z czym, może czasem dojść do sytuacji w której sprawdzenie wielkości strony nie wykona się w odpowiednim czasie, który jest wymagany, aby pokazać wartość przed i po migracji.

Myślisz, czy wiesz? Bo my mamy taki projekt, który to robi i odpytuje wszystkie strony co 2 godziny. Jakimś cudem to działa i zbiera dane już około pół roku . Takich statystyk nie mamy, mamy obecnie tylko listę domen, których to dotyczy. Na szybko mogę sprawdzić ile z tych domen to Wordpress - 41 667 domen. Zapuszczę obliczenie tego i wrócę z wynikami. Z natury cache jest dobry, tam gdzie ma sens. Jeśli na stronę wchodzi 1 osoba dziennie, cache generuje więcej zachodu, niż pożytku. Takie jest moje zdanie. A praktyka mówi, że większość stron nie korzysta z dobrych praktyk, nawet jeśli one są i istnieją. EDIT: Wracam z wynikami. Średni czas wczytywania się dla tych 41 667 domen wynosi: 786 ms z uwzględnieniem lscache i 2543 ms wymuszając wczytanie witryny bez cache

Nie uważam tak, ale masz oczywiście prawo do własnego zdania. Wszystkie domeny odpytujemy co 2 godziny o dane i takie dane też są wyświetlane na stronie każdej domeny. Wskaźnik (ranking) szybciej/wolniej nie mówi o konkretnej pozycji, tylko przedziale w którym strona się znajduje. Ranking dla domeny nie służy do dokładnego monitorowania swojej pozycji, ale do orientacyjnej korelacji prędkości strony w kontekście użytego rozwiązania. Rynek hostingowy w 80-90% dotyczy nie profesjonalistów... Cache to cudowne narzędzie, jeśli umiesz je prawidłowo wykorzystać. Ostatnio robiliśmy badanie ile osób korzysta z super fajnych rozwiązań od Litespeeda. Cache od Litespeed'a jest zaimplementowany tylko na 51 637 stronach, co daje jakieś 2,5% domen które wykorzystują to rozwiązanie. Cache jest fajny, ale dla stron gdzie masz 2 odwiedzających dziennie, nie specjalnie ma to sens...

Nie zrozumieliśmy się, więc jeszcze raz dokładnie. Wartości które przytoczyłeś, dotyczą średniej z doby, a ranking jest generowany na podstawie ostatniego odpytania (odbywającego się co 2h). Wynik tego odpytania znajdziesz w wykresie 10 dniowym. Dodam to przemyślenie do listy rzeczy które moża dołożyć. Nie będę przytaczał konkretnych firm, ale czasem strona z cache działa wolniej u złego operatora, niż strona bez cache u innego. Dużo zależy od sposobu cache, oraz ogólnej infrastruktury operatora. Na przykładzie WordPress, gdzie masz różnych redaktorów, to co im z szybko działającego indeksu, jak panel administratora w którym pracują ładuje się wieczność uniemożliwiając pracę. Nie podchodzimy lekceważąco do cache, dlatego też w przypadku wykrycia cache masz podane dwie wartości czasu wczytywania strony. Niemniej domyślną wartością jest ta, którą uznaliśmy za bardziej ważną i porównywalną. Nawet wychodząc z założenia, że masz rację, to % udziału serwerów VPS i serwerów dedykowanych do hostingu współdzielonego to maksymalnie 5%. Jest to skala pomijalna przy tej liczbie domen.

Ranking jest generowany na podstawie ostatniego sprawdzenia. Zobacz wykres 10 dniowy i będziesz wiedział skąd takie miejsce w rankingu w danej chwili. Pomiar zawsze jest wykonywany z użyciem domyślnie stosowanego protokołu. Jeśli strona przekierowuje na https, to leci po https, jeśli po wejściu na domenę.pl ładuje się strona http, leci po http. Wykresy cache są mniej ważne i zbierane z mniejsza częstotliwością. Dlatego też są widoczne tylko z wartościami uśrednionymi dziennymi. Wartości cache są podglądowe i z naszego punktu widzenia dużo mniej istotne. Badamy wydajność stron, a tutaj chcemy mieć wyniki które są powtarzalne, a te uzyskujemy tylko odpytując o nie cachowane dane. Codziennie odpytujemy 2 mln stron, więc musimy iść na pewne uproszczenia. Z naszego punktu widzenia, nie ma znaczenia czy strona jest taka sama, czy nie. Większość stron jest dynamicznie generowana z dynamicznym kontentem, więc porównywanie ich mijałby się z celem. Rozmiar daje podgląd obrazowy na to co się dzieje, czy nie mieliśmy przypadku przejścia z strony na np. zaślepkę.

nazwa.pl z ostatniego odczytu wypada średnio na poziomie 692 ms, podczas gdy średnia dla polskiego rynku wynosi około 1592 ms. Daje to około 60% lepszy wynik niż średnia, co uważam za bardzo dobry wynik. Statystyka dla nazwy opiera się na odpytaniu ponad 30 tysięcy witryn, zaś średnia jest liczona na podstawie ponad 546 tysięcy witryn Wordpress. Wiadomo, żadne metody statystyczne, nie są w 100% doskonałe, ale przy tak dużej skali sprawdzanych danych, powinny być zbliżone do rzeczywistości. Widać, że zarzucasz innym brak kompetencji, czasem bezpodstawnie atakując innych, samemu nie mając pojęcia o rynku. Na czas wczytywania się stron w dużej mierze wpływa czas generowania stron, a nie prędkość łącza. Jeśli strona zajmująca 1MB, to na łączu 10 Mbit przesłanie jej zajmie 0,8 sekundy, podczas gdy na 100 Mbit zajmie to 0,08 sekundy. Przypominam, że na czasie samego generowania strony średnią mamy na poziomie 1,6 sekundy... Patrząc jeszcze po danych statystycznych to: Obstawiam, że internet stacjonarny jest jeszcze szybszy, więc udział czasu przesyłania danych w pomiarach prędkość wczytywania stron jest dużo niższy, niż w moich powyższych wyliczeniach. @Maxx nie wiem skąd u Ciebie tyle agresji, wrzuć na luz. Każda firma ma prawdo do kształtowania swojej oferty i to klienci są od weryfikacji sensu wprowadzenia usługi do oferty, a nie anonimowy trol z forum. Przyszedłeś na forum i jedyne Twoje "merytoryczne" działanie, to atakowanie konkretnej firmy zachowując anonimowość, zachowując się jak dziecko, mówisz starszym jak mają żyć. Dorośnij ;-).