-
Postów
142 -
Dołączył
-
Ostatnia wizyta
-
Wygrane w rankingu
17
Typ zawartości
Profile
Forum
Wydarzenia
Odpowiedzi opublikowane przez sebak
-
-
@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.
-
1
-
-
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ł
.
-
1
-
-
@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.
-
1 godzinę temu, Maxx napisał(a):
Czy uważasz że to jest logiczne ? Bo dla mnie logiczne jest zebranie tych informacji w jednym zapytaniu, zarówno odnośnie IP, wielkości strony jak i czasu jej wczytywania. A to że nie potrafisz sobie z tym poradzić wynika jedynie z braku doświadczenia. Co nie zmienia jednak faktu, iż rezultatem tak prymitywnej metodologii zbierania danych może być wyłącznie chaos i zamieszanie.
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...
1 godzinę temu, Maxx napisał(a):Z tego co widzę, wykresy bazują na 10 dniach przed i 10 dniach po migracji. A więc logiczne jest iż powinieneś mieć po 10 próbek wielkości strony zarówno przed jak i po migracji zgodnie z tym co wyżej napisałeś. Moje pytanie więc brzmi: gdzie one są ? Bo starasz się powoływać na logikę, której Twoje pokrętne tłumaczenia całkowicie zaprzeczają.
Zachęcam przejrzeć metodologię pomiarów. Curl, chyba nie jest poleceniem zbyt trudnym w obsłudze dla takiego profesjonalisty, więc powinieneś zrozumieć...
-
1
-
-
6 godzin temu, Maxx napisał(a):
Kogo Ty Tomku chcesz w balona zrobić i po raz już któryś z kolei oszukać użytkowników forum ? Wszędzie są podane rozmiary strony przed i po przenosinach. Wszędzie ... za wyjątkiem Twojego przykładu. Czym tylko potwierdziłeś moje podejrzenia odnośnie "niezależności" tego "narzędzia" które również przez "przypadek" Ty wypromowałeś.
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.
-
4 godziny temu, Maxx napisał(a):
Myślę że, nie bardzo to jest możliwe nie mając wpisanych na białą listę przez usługodawców IP z których skanujesz strony. Gdyż na niektórych IP jest nawet kilkadziesiąt tysięcy domen a dodając do tego kilka zapytań o każdą domenę - z automatu otrzymałbyś bana. Zgadza się ?
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
.
4 godziny temu, Maxx napisał(a):Jaki daje to realny zysk w przypadku WP ? Możesz podać jakieś dane porównawcze, odnośnie TTFB przy wykorzystaniu tego rozwiązania jak i przy jego braku ?
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.
4 godziny temu, Maxx napisał(a):Cache w przypadku WP zawsze ma sens. Gdyż nawet jak ze strony ludzi byłoby ZERO wizyt - obciążenie generują wszelakiej maści boty, a czym większa strona tym ruch przez nie generowany jest większy. Dzięki temu na tym samym hostingu/serwerze swobodnie można trzymać znacznie więcej stron niż w przypadku gdy cache nie jest używany. Gdyż WP nie został napisany by być wydajnym a uniwersalnym i przez tą uniwersalność jest bardzo zasobożerny. I dlatego cache w przypadku WP zalicza się do kategorii "must have".
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 i2543 ms wymuszając wczytanie witryny bez cache
-
17 godzin temu, Maxx napisał(a):
Jak sam widzisz, na stronie macie dużo niejasnych kwestii wprowadzających użytkownika w błąd, jak na przykładzie powyżej
Nie uważam tak, ale masz oczywiście prawo do własnego zdania.
17 godzin temu, Maxx napisał(a):Dodatkowo przy aktualizowaniu tylko części domen co 2h tenże ranking (ile stron wczytuje się szybciej/wolniej) to jeden wielki chaos i nieporozumienie. Ale to Wasza piaskownica, więc możecie prezentować dane jak tylko zechcecie. Jednak musicie wziąść pod uwagę, iż nie wszyscy użytkownicy przeglądają wspomniany wykres, który w dodatku domyślnie pokazuje dane z 3-ch miesięcy a nie 10 dni, o czym wspominałem już wcześniej i co tylko pogłębia wspomniany chaos.
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.
17 godzin temu, Maxx napisał(a):Dlatego właśnie profesjonaliści korzystający z WP używają CACHE a amatorzy szukają szybszych procesorów których stronki WP bez CACHE i tak można skutecznie zarżnąć już kilkudziesięcioma zapytaniami na sekundę. Że już o szybkim osiągnięciu progów bezpieczeństwa nie wspomnę.
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...
-
45 minut temu, Maxx napisał(a):
Nie chodzi mi o miejsce w rankingu ale kwestię że ilość szybszych stron jest podawana błędnie. Gdyż nie jest możliwe aby aż 21 % stron ładowało się szybciej niż 369 ms i jednocześnie aby tylko 5 % ładowała się szybciej od znacznie dłuższego czasu ładowania tj. 436 ms. Gdyż jest oczywiste, że ze wzrostem czasu ładowania coraz więcej stron jest szybszych a nie na odwrót jak na przytoczonym przykładzie.
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.
47 minut temu, Maxx napisał(a):To można się dowiedzieć z metodologii opisanej na stronie. Ale jaki został użyty protokół należało by uwzględnić w prezentowanych wynikach gdyż wpływa to na prezentowany wynik.
Dodam to przemyślenie do listy rzeczy które moża dołożyć.
48 minut temu, Maxx napisał(a):Jeśli komuś zależy na szybkości strony - hostingu nie zmienia po to by jarać się czasem generowania strony ale by jego klientom strona ładowała się jak najszybciej. A w przypadku WP bez użycia CACHE nie jest możliwe zejść do max kilkudziesięciu ms z TTFB które ma kluczowe znaczenie dla szybkości wczytywania strony. Ponadto cache generowane jest raz i w rzeczywistym świecie to właśnie z niego serwowane są odsłony. I dlatego nie należy podchodzić lekceważąco do tego, co ma naprawdę duże znaczenie.
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ą.
58 minut temu, Maxx napisał(a):Jeśli z kolei chodzi o wydajność - wrzucacie do jednego wora hostingi za kilka złotych oraz VPS-y i dedyki za kilka stów co przy braku informacji z czego korzysta dana strona jest mówiąc delikatnie - mało przydatne gdy dany dostawca oferuje wiele rozwiązań. A to z kolei podwyższa średni wynik dla największego dziadostwa i obniża dla wysokiej klasy rozwiązań.
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.
-
15 godzin temu, Maxx napisał(a):
@sebak Wyjaśnisz mi proszę, jak to jest możliwe że 21 % stron ładuje się szybciej niż 369 ms, podczas gdy tylko 5 % ładuje się szybciej niż 436 ms ?
Ranking jest generowany na podstawie ostatniego sprawdzenia. Zobacz wykres 10 dniowy i będziesz wiedział skąd takie miejsce w rankingu w danej chwili.
15 godzin temu, Maxx napisał(a):- Nie jest jasne, czy pomiary zostały dokonane przy użyciu HTTPS czy HTTP.
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.
15 godzin temu, Maxx napisał(a):- Na wykresie z 10 dni, nie ma wyników z CACHE, które są na wykresie z 3 m-cy
Wykresy cache są mniej ważne i zbierane z mniejsza częstotliwością. Dlatego też są widoczne tylko z wartościami uśrednionymi dziennymi.
15 godzin temu, Maxx napisał(a):- Domyślnie powinien być przedstawiony wynik z CACHE + informacja o tym fakcie, lub oba, gdyż również nie jest jasne czego średnia się tyczy w przypadku gdy CACHE jest włączone.
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.
16 godzin temu, Maxx napisał(a):- Przy wykryciu zmiany hostingu, nie sprawdzacie czy pod domeną jest ta sama zawartość, czego efektem jest np. 30 KB przed zmianą i 60 KB po zmianie i nie wiadomo czy wynika to ze zmiany zawartości, szablonu, wtyczek czy choćby z włączonej kompresji GZIP a wszystko wymienione. A ma to wpływ na wynik podobnie jak użycie HTTPS zamiast HTTP
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ę. -
6 godzin temu, Maxx napisał(a):
W żadnym z tych testów nazwa.pl nie jest na pierwszym miejscu, więc wynika z nich jedynie, iż nazwa.pl w niczym nie jest liderem oprócz marketingowego bełkotu który tylko potwierdza, iż ta krowa która najgłośniej ryczy najmniej mleka daje. Ponadto aby jakikolwiek test był wiarygodny, muszą być stworzone identyczne warunki - czyli w przypadku bloga WP - przede wszystkim taki sam szablon i te same wtyczki oraz taka sama ilość (i objętość) zarówno strony głównej jak jej zawartości w postaci grafik/zdjęć.
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.
6 godzin temu, Maxx napisał(a):A nawet mimo stworzenia takich warunków wciąż wyniki będą dalekie od rzeczywistości gdyż nie uwzględniają szybkości łącz konsumenckich gdzie przy wielkości strony 10 MB i szybkości łącza konsumenckiego 10 Mbit wynik testu będzie wprowadzał w błąd na łączu serwerowym 100Mbit a błąd będzie dziesięciokrotny w stosunku do rzeczywistości. I choćby nie wiem jak szybki i wydajny był serwer źródłowy, nie jest możliwe aby czas ładowania strony spadł poniżej 10 sekund przy w/w warunkach podczas gdy test na serwerze 100Mbit może pokazać czas ładowania 1 sekundę - dlatego tego typu testy są całkowicie bezużyteczne.
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:
CytatŚrednia prędkość pobierania danych za pomocą internetu mobilnego w drugiej połowie 2022 r. wyniosła w Polsce 38,9 Mb/s.
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 ;-).
-
1
-
-
Nie będę wypowiadał się na tematy marketingowe, ale w kwestii wydajności muszę stanąć po stronie nazwa.pl. Są jedną z najszybszych firm hostingowych w Polsce, tak przynajmniej wynika z naszych testów na https://webspeed.pl. Nawet jeśli ich CDN, nie jest doskonały, to istotnie mało innych firm z naszego polskiego podwórka oferuje podobnego typu usługi. @Maxx pełna zgoda, że wszystko da się zrobić lepiej, ale patrzmy realnie na rynek, a tutaj nazwa.pl jeśli chodzi o wydajność jest w ścisłej czołówce.
-
To właśnie różni projekty hobbistyczne, od komercyjnych, że tutaj zmian zazwyczaj dokonuje się w dni wolne i po pracy
.
-
1
-
-
2 godziny temu, Tom X napisał(a):
Tylko, że to IMO nie działa poprawnie. Zerknij na dane liczbowe, kolorystykę tła, kierunek i kolor strzałki, komentarz (SZYBKO, MOGŁO BYĆ LEPIEJ) z załączonych grafik.
Faktycznie, naprawione. Dzięki za czujność.
-
1
-
-
2 godziny temu, Tom X napisał(a):
Co by się stało, gdyby skala per operator była ujednolicona ze skalą per storna?
Żaden operator nie spada poniżej 500ms z średnią, wiec każdy byłby pomarańczowy lub czerwony.
Z racji na filtrowanie rankingów łatwiej zastosować per operator 3 progi, bo łatwo można je opisać: szybko, wolno, średnio. Podobnie jak sortowanie po zmianie ilości obsługiwanych domen, tez ma 3 progi: wzrost, spadek, bez zmian.
-
@Tom X zerknij na to w wolnej chwili, zostało to zmienione zgodnie z Twoją sugestią. Dzięki.
-
1
-
-
@Tom X to nie subdomena, ale średnia z wszystkich stron wordpress dla home.pl
. Trzeba było użyć jakiegoś klucza, pod którym moglibyśmy zapisywać te dane.
Tutaj mamy problem i w sumie nie wiem jeszcze jak do niego podejść. Co innego przedziały dla konkretnej witryny, a co innego średnia per operator. Stosując się do tych samych wytycznych tu i tu, żaden operator nie załapałby się na kolor zielony, mimo iż około 22% stron Wordpress i 52% Prestashop wczytuje się poniżej 400 ms. Obecne przedziały dla operatorów to:
0-750 ms - szybko
750 ms - 1,5 sekundy - średnio
powyżej 1,5 sekundy - wolno
Jesteśmy otwarci na wszelkie propozycje, więc jeśli masz pomysł jak to najlepiej rozwiązać, z chęcią skorzystamy.
-
3 godziny temu, ksk napisał(a):
Chyba się kasa nie zgadza w cyber_folks .
Dostałem ostatnio maila aby zostać ich inwestorem . Za zostanie inwestorem oferują rabaty na usługi.
Śledząc nasz rankingi, to kondycja cyberfolks prezentuje się bardzo dobrze:
https://webspeed.pl/rankingi/wordpress
Więc raczej to jest kwestia tak jak napisał @Tom X zwiększenia zaangażowania klientów, lub myślą o jakiejś ekspansji ;-).
-
1
-
-
W przytoczonym przez Ciebie screenie z Twojej przeglądarki widać, że masz rozbieżność na poziomie ~40% między dwoma odczytami z małym przedziałem czasowym. Serwer z zależności od obciążenia, może serwować stronę w różnym czasie, może trafiliśmy na czas gdy akurat serwer nie domagał. Pytanie czy problem dotyczy jednego zapytania, czy jest to trend ciągły?
Pytając o stronę, pytamy zawsze o stronę główną na potrzeby czasów. Z /feed brana jest tylko wersja Wordpress, o ile taka występuje w /feed. Nasze zapytanie stara się odpytywać stronę bez cache.
-
Kod odpowiadający za wykrywanie CMS’a przewinął się kilka postów temu. Jeśli masz lepsza propozycję, z chęcią ją zastosujemy.
-
Od 0 do 6 robi się proces discovery, który wykrywa CMS’a, operatora oraz wszystkie inne zmienne witryny. Więcej możesz poczytać tutaj: https://webspeed.pl/about
Od 6 do 24 robi się proces sprawdzania wydajności www, który bazuje już wcześniej przygotowanych danych. W najnowszej wersji check-url nie korzystamy już z serwera DNS, tak by aspekt odpowiedzi DNS nie wpływał na zaburzenia pomiarów.
PS: @Kapitan_Bomba dzięki wykrywaniu stron Wordpress, powstał ranking operatorów pod względem ilości hostowanych stron tego typu: https://webspeed.pl/rankingi/wordpress
Nowy serwis testujący TTFB stron internetowych webspeed.pl
w Pozostałe
Opublikowano
@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 ;-).