Nowy serwis testujący TTFB stron internetowych webspeed.pl

[spex]

20 godzin temu, sebak napisał(a):

Masz rację co do błędów, jak pisałem, postaramy się to poprawić zgodnie z Twoimi sugestiami. Niemniej, to o czym mówisz, jest trochę jak błąd pomiarowy. Rzadko się dzieje, by normalnie ktoś delegował dns'yp do np. nazwy.pl, a trzymał domenę w innej formie. Na moje oko takich klientów jest poniżej 1%. Przeważająca liczba wszystkich witryn bazuje na WordPress, więc są to duże liczby. Przy tej skali jest to pomijalny błąd pomiaru.

 

Nie jestem pewien, ale chyba to był jedyny sposób na działanie w środowisku gdzie poczta jest w home.pl, ale www już została zmigrowana gdzieś indziej.

NS na home.pl i dopiero tam A w świat. Bo poczta home.pl nie działała z samym wskazaniem jej jako mx

[Tom X]

13 godzin temu, sebak napisał(a):

 

Mechanizm ustalania CMS nie jest zbyt skomplikowany i działa tylko na statusach http.

Dzięki za wyjaśnienia.

[sebak]

Jak by pojawiły się jakiekolwiek pytania z chęcią wyjaśnię, czy pokaże jak to działa.

Edytowane 18 Sierpnia 2023 przez sebak

[sebak]

Mam pewien pomysł i chciałbym go z wami przedyskutować.

 

Chciałbym liczyć średnią per adres IP. W związku z tym mam kilka pytań:

• Od jakiej ilości domen na danym adresie IP liczenie takiej średniej ma sens?
• Liczymy średnią dla wszystkich stron, czy średnie dla konkretnej kategorii stron np. Wordpress?
• Liczymy i podajemy tylko aktualną średnią, czy zapisujemy też dane historyczne?

Sugestie nie związane też z pytaniem są mile widziane.

 

@itomek napisaliśmy już mechanizm do weryfikacji operatora po IP rekordu A (nie delegacji dns). Całość przechodzi testy i zostanie zaimplementowana w przyszłym tygodniu.

[ksk]

Podoba mi się ten projekt i chętnie go wesprę .

Jeśli potrzebujecie jakaś maszynę ( VPS ) w lokalizacji FR  to chętnie wspomogę taką za darmo

Może przyda się dodatkowe sprawdzanie z innej lokalizacji .

[sebak]

@ksk dzięki za propozycję. Chwilowo chcemy skupić się na dopracowaniu tego co jest oraz zrobieniu tego w taki sposób, aby nie było wątpliwości co do sposobu działania. Jak przebrniemy przez ten etap, będziemy myśleć o rozbudowie projektu o nowe funkcjonalności. Sam skrypt jest zrobiony tak, że rozbudowanie go o dodatkowe lokalizacje nie powinno stanowić problemu.

 

 

[psz]

W dniu 19.08.2023 o 09:41, sebak napisał(a):

Chciałbym liczyć średnią per adres IP. W związku z tym mam kilka pytań:

• Od jakiej ilości domen na danym adresie IP liczenie takiej średniej ma sens?
• Liczymy średnią dla wszystkich stron, czy średnie dla konkretnej kategorii stron np. Wordpress?
• Liczymy i podajemy tylko aktualną średnią, czy zapisujemy też dane historyczne?

 

Od żadnej. Adresy IP mają funkcję infrastrukturalną (gdzie kierować ruch, aby mógł zostać przetworzony), a nie identyfikacyjną (co stoi za adresem).

[sebak]

@psz dla mnie z kolei to wydaje się bardzo ciekawe. W większości IP mówi na którym jesteś serwerze w przypadku hostingu współdzielonego. A co za tym idzie, jeśli masz problem z ładowania się strony, możesz zweryfikować, czy nie dotyczyło to wszystkich stron z danego serwera.

[psz]

Mocno naciągana teoria.

 

O ile "IP == Serwer" będzie prawdziwe w przypadku najprostszych hostingów/homelabu, to w przypadku usług cloud, a nawet średniej wielkości hostingów, masz do czynienia z całym klastrem load balancerów, aplikacyjnych, SAN, bazy danych itp. W dodatku ten IP będzie się różnił w zależności od sytuacji, np. CDN-y z anycastem lub geodns, gdzie cały kontynent będzie miał jedno IP, albo IP per operator/losowe; czy jest atak DDoS i ruch idzie przez scrub serwery; hostingi sprzedające VPS-y bez IPv4 (i w zamian oferujące proxy), albo domowe homelaby za CGNAT-em (są ISP, które pozwalają klientom przekierowywać sobie porty, w podobny sposób, w jaki domowe routery to udostępniają) itp. IP mają tendencję się też zmieniać, czasem nawet co kilka sekund (o ile klient nie kupi sobie dodatkowo płatnej usługi statycznego IP, co firmy lubią wciskać jako usługę premium, choć klient często nie wie, po co).

 

Oczywiście, nic nie broni Wam dodać takiej statystyki, ale będzie to zabawka, a nie wartościowa miara.

[sebak]

@psz z tego co przeglądam polski rynek hostingowy, to to o czym mówisz występuje w bardzo niewielkim stopniu. Owszem masz pełną rację, że w takim przypadku dane będą bezwartościowe, ale jednak 90% firm u nas nie korzysta z tego typu rozwiązań. Pracujesz u lidera technologicznego, więc myślę, że patrzysz przez ten pryzmat na całą branżę, która jest miejscami dość mocno zacofana ;-).

[psz]

Heh, niestety twoje ostatnie zdanie jest tu kluczowe. O ile wiedzy w kraju nam nie brakuje, to czuję, że ciągle króluje zasada "byle taniej". Jednak na świecie pełno jest "zacofanych" hostingów, czego (zgodnie z zasadą wierzchołka góry lodowej) po prostu nie widać, bo co bardziej nowoczesne mają proporcjonalnie najwięcej klientów.

[kafi]

Niekoniecznie to musi być kwestia zasady "byle taniej" czy zacofania.

 

Klastrowanie aplikacji webowych efektywne jest tylko wtedy, gdy taka aplikacja jest do tego klastrowania przygotowana.

W innym przypadku będzie to robić więcej problemów niż będzie z tego pożytku.

A nie oszukujmy się, tandem php+mysql i większość aplikacji w nim z samej swojej definicji się do tego nie nadaje.

Bo a to sposób identyfikacji klienta końcowego (widziany przez aplikację adres IP użytkownika końcowego), a to sesje w plikach, a to nieobsługiwane deadlocki w bazie danych, a to dziwnie dynamicznie generowany content powoduje, że nie da się tego zamknąć w ładne uniwersalne pudełko; tylko trzeba do każdej appki podchodzić względnie indywidualnie.

 

Nic więc dziwnego, że dostawcy, chcąc aby platforma była jak najbardziej uniwersalna, zamykają się w dużej mierze do jednego serwera na jednym adresie IP (lub wielu adresach, ale kierujących na ten sam serwer) z ewentualnym failoverem na drugi.

 

 

Dla mnie analiza tego, co dzieje się na innych serwisach pod podanym IP, jak i też na innych adresach IP w netblocku danej firmy hostingowej by była całkiem ciekawa.

Mogło by to zawierać krótkie dane historyczne (np. ze 3 dni) co by móc sobie sprawdzić czy to nie flappuje jakoś jak się u siebie widzi problemy.

Tylko warto by te adresy IP skategoryzować na takie "końcowe" używane przez firmy hostingowe i wszelakich "pośredników" - bo mierzenie średniego TTFB węzła sieci CloudFlare czy quic.cloud'a niezbyt powie coś wartościowego i szkoda na to marnować zasobów

 

 

Tak czy inaczej, nawet w obecnej formie przygotowaliście bardzo ciekawy serwis, powodzenia!

[jvr]

Mnie zastanawia zachowanie SDC. Na pewno też otrzymywali podobne sygnały na potęgę.

[Tom X]

W dniu 18.08.2023 o 12:43, sebak napisał(a):

Jak by pojawiły się jakiekolwiek pytania z chęcią wyjaśnię, czy pokaże jak to działa.

 

Skuszę się.

1. Dlaczego przycisk z cyfrą/liczbą w środku nie jest opisany: co oznacza 6, dlaczego nie 17 albo 3, co oznacza strzałka w górę, jaki skutek powoduje kliknięcie przycisku?
2. Po kliknięciu nieopisanego przycisku, użytkownik dowiaduje się, że wziął udział w ankiecie. Dlaczego użytkownik dowiaduje się, że bierze udział w ankiecie po fakcie a nie przed?
3. Dlaczego w ankiecie jest tylko jedna propozycja i na jakich zasadach została ona wyłoniona z innych (jakich)?
4. Ile, zdaniem autorów ankiety, warte są głosy użytkowników, którzy nie wiedzieli/rozumieli w czym biorą udział i na jakich zasadach?

[kafi]

Yyy... ty tak serio, czy kolejny raz szukasz po prostu powodu do zaczepki  ?

 

Postaram ci się wywróżyć odpowiedź na bazie doświadczeń z innymi listami community-to-do.

Jak dodasz pomysł, to dodaje się do listy z zerem głosów (być może po moderacji nowych wpisów).

Jak klikniesz strzałkę w górę to zwiększasz liczbę głosów na wybraną propozycję o jeden.

Liczba głosów to właśnie ta cyferka w ramce.

 

W większości takich rozwiązań jest jeszcze "łapka w dół" do wyboru, tu nie ma, no ale to taki szczegół.

[sebak]

@Tom X już odpowiadam:

 

1. Liczba 6 oznacza ilość oddanych głosów na daną propozycję. Strzałka w górę i kliknięcie na przycisk oznacza głos na daną propozycję. Jest to klasyczne działanie tego typu narzędzi. 

2. Jest to klasyczne działanie tego typu narzędzi, więc wydawało nam się, że dla większości osób jest to zrozumiałem i logiczne. Wychodząc na przeciw Twoim oczekiwaniom, zmodyfikowaliśmy stronę i dodaliśmy tooltip z informacją co się stanie po kliknięciu.

3. Jest jedna pozycja, bo tylko ta jedna pozycja została obecnie dodana przez naszą społeczność. Propozycje może dodać każdy, od tego masz formularz powyżej. Jeśli społeczność doda więcej propozycji, będzie ich więcej na liście.

4. Jak już pisałem, jest to klasyczne podejście do tematu(branżowy standard), ale idąc za Twoją sugestią dodaliśmy szczegółowy opis.

 

Dzięki za sugestie, jak coś jeszcze znajdziesz daj znać, poprawimy.

[Tom X]

@sebak

Środowiska branżowe często idą na skróty, uznając pewne rozwiązania za oczywiste, niewymagające dookreślenia. Nie byłem pewien zachowania przycisku. Tooltip wydaje się wystarczający. Dzięki za wyjaśnienia.

[sebak]

@Tom X dlatego też dzięki za sugestie, na podstawie których wprowadziliśmy poprawki. Poza toltipem, masz na stornie link do pełnego opisu sposobu działania listy.

[Tom X]

11 minut temu, sebak napisał(a):

@Tom X dlatego też dzięki za sugestie, na podstawie których wprowadziliśmy poprawki. Poza toltipem, masz na stornie link do pełnego opisu sposobu działania listy.

Znakomicie!
Czy nie będę przesadnie zrzędliwy, gdy wskażę dwie drobne literówki?
"jesteśmy otwarci na Twoje pomysł" -> pomysły
"pozwoli innym osobom na oddawania na nie swoich głosów" -> oddawanie
Nie mam więcej pytań.

[sebak]

Oczywiście, że nie, dzięki Tobie stajemy się lepsi . Dziękujemy i poprawione.

[sebak]

@itomek zgodnie z nasza obietnicą i po gruntownych testach rozpoznawanie operatora zostało zmienione. Obecnie operatora rozpoznajemy na podstawie rekordu A (poprzednio na podstawie delegacji dns). Jednocześnie generując wykres przed i po zmianie operatora, za dzień zmiany bierzemy zmianę adresu IP (poprzednio zmianę delegacji dns). W widoku "historia zmian" dodaliśmy też zmiany adresów IP.
 

W dniu 16.08.2023 o 13:39, itomek napisał(a):

Tu jako przykład pod pytanie podam raport https://webspeed.pl/wynajem-maszyn.com.pl, z którego mogę się dowiedzieć, że cyt: "Zmiana serwera z kei.pl na nazwa.pl okazała się minimalna. Domena wynajem-maszyn.com.pl z nowego serwera wczytuje się z podobną szybkością." oraz "System wykrywa zmianę wskazania domeny na nowy serwer DNS. Nie musi to oznaczać zmiany usługi hostingowej. Wykres pozwala właścicielowi domeny ocenić zmianę, której dokonał. Metodologia.".  I wszystko byłoby ok, ale... strona wynajem-maszyn.com.pl nie jest utrzymywana  na serwerze nazwa.pl, tylko na serwerze cyber_Folks, co widać chociażby po raporcie MTR i informacjach o IP tutaj https://www.test2speed.pl/report/wynajem-maszyn.com.pl/mZ3jaeoi  .

 

Zerknij teraz, wszystko powinno być już poprawnie, dla tej, jak i innych domen .

 

Jeśli masz jeszcze jakieś sugestie, czekamy na nie z niecierpliwością , a za dotychczasowe ślicznie dziękujemy .

[itomek]

W dniu 29.08.2023 o 13:50, sebak napisał(a):

@itomek zgodnie z nasza obietnicą i po gruntownych testach rozpoznawanie operatora zostało zmienione. Obecnie operatora rozpoznajemy na podstawie rekordu A (poprzednio na podstawie delegacji dns). Jednocześnie generując wykres przed i po zmianie operatora, za dzień zmiany bierzemy zmianę adresu IP (poprzednio zmianę delegacji dns). W widoku "historia zmian" dodaliśmy też zmiany adresów IP.

 

Fajnie, że udało się to wprowadzić. Czy weryfikujecie adres IP widoczny w ustawieniach DNS domeny, czy jest to IP pobierany z docelowego hosta, z którego przychodzi odpowiedź 200? Dlaczego o tym piszę - otóż weryfikując to na przykładzie domen utrzymywanych u nas, ok 30 tysięcy z nich, mimo że korzysta z naszych DNSów, ma przekierowania na strony w innych firmach lub nawet na serwery bezpłatne. Skoro akceptujecie w swoim zapytaniu 301, to gdyby weryfikować rekord A ze strefy DNS, wszystkie wyniki tych domen będą przypisane do nazwa.pl, podczas gdy faktycznie za realne TTFB strony będą odpowiadały inne firmy hostingowe / inni usługodawcy.

 

Odniosę się też do zmiany DNSów, bo to jest powiązane z powyższym. Jak ustaliliśmy, zmiana DNSów nie oznacza zmiany hostingu. Dodatkowo jednak trzeba wziąć więc pod uwagę fakt, że zmiana rekordu A też nie będzie oznaczała zmiany hostingu. Rekord A może się zmienić lub nie, ale dalej może być właśnie to przekierowanie 301, które to trzeba wziąć pod uwagę. Gdyby nie fakt, że udało mi się u nas znaleźć ok. 30 tyś takich domen, uznałbym to za potencjalnie nieistotny błąd statystyczny. Jednak taka liczba może wpływać na wyniki, a to tylko liczba u jednego dostawcy, którym jest nazwa.pl.

[sebak]

Zacznę może od początku. Akceptujemy 301 tylko w procesie discovery(odpalany raz na dobę). Proces ten po wejściu na stronę główną np. http://nazwa.pl sprawdza czy następuje przekierowanie, jaką ma formę oraz gdzie prowadzi docelowy adres URL. Jeśli adres URL wychodzi poza sprawdzaną domenę, taką domenę oznaczamy jako "ghost" i nie sprawdzamy dla niej danych na poziomie procesu check-url (pracującego co 2 godziny). Taka domena nie jest brana pod uwagę w rankingu, jak też nie zbieramy dla niej żadnych informacji, gdyż było by to bezcelowe.

 

Sam proces sprawdzania czasów generowania stron nie pozwala na przekierowania, oraz wczytuje stronę już po docelowym adresie URL, który został uzyskany procesem discovery.

 

Dlatego też problem o którym mówisz, nie będzie u nas występował, bo zabezpieczyliśmy się na taką ewentualność. Schemat działania opisałem Ci powyżej. Mam nadzieję, że to rozwiało Twoje wątpliwości.

 

9 minut temu, itomek napisał(a):

Odniosę się też do zmiany DNSów, bo to jest powiązane z powyższym. Jak ustaliliśmy, zmiana DNSów nie oznacza zmiany hostingu.

 

Tak, dlatego cały mechanizm wykrywania zmiany hostingu został mocno przebudowany. Jeśli wykryliśmy zmianę DNS, weryfikujemy adresy IP przed i po zmianie. Tylko jeśli należą do innych firm, wtedy wyświetlamy informację o zmianie operatora. Datę zmiany ustalamy na podstawie daty zmiany adresu IP i weryfikacji czy zmienił się właściciel danego adresu IP. Firmy przed i po zmianie ustalamy na podstawie adresu IP na który wskazuje domena, nie po adresach DNS. Dla każdej domeny w historii zmian masz informację o Adresie IP, DNS oraz do kogo przyporządkowaliśmy adres IP. 

 

15 minut temu, itomek napisał(a):

Rekord A może się zmienić lub nie, ale dalej może być właśnie to przekierowanie 301, które to trzeba wziąć pod uwagę.

 

Wzięliśmy to pod uwagę już od samego początku projektu i taki problem nie powinien występować. Przekierowanie na inną domenę z automatu powoduje, że strona jest nie uwzględniona w rankingu.

 

A teraz kilka liczb, dla osób które lubią liczby by przytoczyć jak to wygląda:

- 2 685 152 - tyle domen mamy w bazie
- 2 288 028 - tyle domen po ostatnim discovery poprawnie odpowiadało na zapytanie dns
- 576 096 - tyle domen mamy oznaczone jako domeny duchy. Aby stać się duchem trzeba spełnić jednej z następujących warunków: 301 na zewnętrzną domenę lub NS oraz IP parkingu domen.
- 1 711 932 - dla tylu domen dzisiaj robimy proces check-url (wartość mniejsza niż poniższą, bo czasem ktoś np. nie odnowi domeny na czas, wtedy wypada z dziennego sprawdzania, ale dane historyczne pozostają)
- 1 797 697 - dla tylu domen mamy dane o historii strony

W razie wszelkich pytań, będę starał się odpowiadać na bieżąco.

PS: Założyliśmy Instagram projektu i zachęcamy do obserwowania nas: https://www.instagram.com/webspeed.pl/ Będziemy dzielić się tam ciekawymi danymi statystycznymi.

[itomek]

17 godzin temu, sebak napisał(a):

Proces ten po wejściu na stronę główną np. http://nazwa.pl sprawdza czy następuje przekierowanie, jaką ma formę oraz gdzie prowadzi docelowy adres URL. Jeśli adres URL wychodzi poza sprawdzaną domenę, taką domenę oznaczamy jako "ghost" i nie sprawdzamy dla niej danych na poziomie procesu check-url (pracującego co 2 godziny). Taka domena nie jest brana pod uwagę w rankingu, jak też nie zbieramy dla niej żadnych informacji, gdyż było by to bezcelowe.

 

To bardzo dobra informacja. Nie ma tego w opisie metodologii, stąd moje poprzednie pytanie. Cieszę się, że tak to rozwiązaliście 

 

17 godzin temu, sebak napisał(a):

Tak, dlatego cały mechanizm wykrywania zmiany hostingu został mocno przebudowany. Jeśli wykryliśmy zmianę DNS, weryfikujemy adresy IP przed i po zmianie. Tylko jeśli należą do innych firm, wtedy wyświetlamy informację o zmianie operatora. Datę zmiany ustalamy na podstawie daty zmiany adresu IP i weryfikacji czy zmienił się właściciel danego adresu IP. Firmy przed i po zmianie ustalamy na podstawie adresu IP na który wskazuje domena, nie po adresach DNS. Dla każdej domeny w historii zmian masz informację o Adresie IP, DNS oraz do kogo przyporządkowaliśmy adres IP. 

 

Patrząc na wcześniejszą odpowiedź, wydaje mi się, że teraz badanie DNS nie jest do niczego potrzebne. Skoro zmianę operatora wykrywacie po zmianie IP i porównaniu, który hosting obsługuje nowy adres, a który obsługiwał stary adres, to wydaje mi się, że ten element można byłoby pominąć?

[sebak]

2 godziny temu, itomek napisał(a):

To bardzo dobra informacja. Nie ma tego w opisie metodologii, stąd moje poprzednie pytanie. Cieszę się, że tak to rozwiązaliście 

 

Jest ;-). Masz przykład curl'a do ustalania adresu URL. Tam masz parametr odpowiadający za przekierowania:

-L --max-redirs 5

Gdzie przy procesie sprawdzania strony te parametry nie występują.

 

2 godziny temu, itomek napisał(a):

Patrząc na wcześniejszą odpowiedź, wydaje mi się, że teraz badanie DNS nie jest do niczego potrzebne. Skoro zmianę operatora wykrywacie po zmianie IP i porównaniu, który hosting obsługuje nowy adres, a który obsługiwał stary adres, to wydaje mi się, że ten element można byłoby pominąć?

 

Można było by pominąć, ale z racji tego, że wychodziliśmy od sprawdzania dns, a dopiero później dopisywaliśmy dodatkowe weryfikacje, to było by to trudne do pominięcia, bez przepisywania dużej części kodu.