Skocz do zawartości
  • Cześć!

    Witaj na forum RootNode - aby pisać u nas musisz się zarejestrować, a następnie zalogować. Posty pisane z kont niezarejestrowanych nie są widoczne publicznie.

Wydajność HTTP/2


smarthost
 Udostępnij

Rekomendowane odpowiedzi

Witam,

 

Dzisiaj zgłosił się na nas klient, który testował, czy uruchomione przez nas HTTP/2 jest lepsze niż zwykłe SSL. Ponieważ rozmowa była długa, zacząłem szukać różnych poradników, bo wszyscy piszą, ze http/2 przyspiesza w stosunku do http/1.1, ale ten klient "tego nie odczuwał". Oczywiście temat jest dużo głębszy, bo przy pojedynczym połączeniu małej strony bez obciążenia, to zyski będą minimalne. Ale klienci lubią testować.

 

Znalazłem ciekawą porównywarkę porównującą tą samą stronę po http/1.1 i http/2:

https://tools.keycdn.com/http2-test

 

może się komuś przyda :-)

 

Wojtek

  • Lubię 1
  • Super! 1
Odnośnik do komentarza
Udostępnij na innych stronach

HTTP2 może fajnie spowolnić stronę, jeżeli będzie wczytywanego dużo contentu statycznego i serwer obsługujący go będzie miał słabsze łącze lub wystąpią jakieś anomalia z przepustowością np. w tranzycie do użytkownika.

HTTP pozwoli na wczytanie elementów w osobnych requestach, a HTTP2 będzie spowalniał w jednej transmisji ;)

 

* Testowane na Nginx i serwerze który miał spore zachwiania w transferze do sieci UPC ;)

Edytowane przez patrys
Odnośnik do komentarza
Udostępnij na innych stronach

W temacie: Piotr Stapp (FinAi): HTTP/2 na Ratunek Wydajności Wielu deweloperów pokłada nadzieje w HTTP/2, który już wkrótce ma być powszechny. Ale kiedy wreszcie będzie można go używać? A może już jest gotowy?

 

 

Odnośnik do komentarza
Udostępnij na innych stronach

W temacie: Piotr Stapp (FinAi): HTTP/2 na Ratunek Wydajności Wielu deweloperów pokłada nadzieje w HTTP/2, który już wkrótce ma być powszechny. Ale kiedy wreszcie będzie można go używać? A może już jest gotowy?
 
 
Oczywiście że działa I można go używać i używamy. Co prawda mamy apache 2.4 z modułami Litespeeda ale działa też na apache ze zwykłym FPM.

Mamy na wszystkich serwerach: https://www.smarthost.pl/apache-http2-na-serwerach-smarthostpl

Wojtek

Wysłane z mojego A0001 przy użyciu Tapatalka

Odnośnik do komentarza
Udostępnij na innych stronach

Również wspieramy HTTP/2 ale nie zawsze jest to tak kolorowo. Dokładnie jak to zostało już napisane, wszystko zależy od konstrukcji witryny i odbiorcy który w różny sposób łączy się z internetem. Szybkość samego internetu i moc komputera dalej odgrywa dużą rolę. Niestety twórcy stron/deweloperzy upychają coraz cięższe elementy które tak naprawdę maja mało co wspólnego z wydajnością. Według mnie nie jest to standard który trwale zmieni mechanizm działania serwerów web w odniesieniu klient/serwer. Myślę że pojawi się niebawem coś zupełnie nowego.

Odnośnik do komentarza
Udostępnij na innych stronach

Ale co znaczy że nie jest kolorowo? Ma działać to działa. To że nie przynosi wielkich zysków to już nie jest kwestia hostingodawcy. Bo hostingodawca nie jest twórcą softu ani twórcą stron. 

Dostarcza tylko rozwiązanie. 

 

Teoria jest dobra w przypadku https/2. Ale wymaga chyba dobrze zoptymalizowanej strony: na pewno wielkie i ciężkie obrazki zabiją wydajność rozwiązania. 

 

Wojtek 

Odnośnik do komentarza
Udostępnij na innych stronach

Pisząc że nie jest tak kolorowo właśnie miałem na myśli wszelkiego rodzaju testy przez użytkowników/klientów. Oczekiwania to jedno a realna wydajność to już inna sprawa ,która jak sam napisałeś przestaje mieć dodatnią wartość gdy witryna/projekt wymaga optymalizacji. Również dobrze że użyłeś określenia teoria. Pagespeed od google też był super hiper a wyszło tak że rozwój projektu gdzieś umyka obecnym oczekiwaniom. Pomimo wielu rodzajów/typów serwerów web dalej nie jest rozwiązana główna kwestia jaką jest sama witryna i jest składniki, sam to również zaznaczyłeś kategoryzując role w formie usługodawca -> usługa -> klient i jego witryna. Teoria jest taka by składowe elementy jak najszybciej dodarły do przeglądarki użytkownika. Super, ale co gdy tak się nie dzieje? Rozwiązanie typu HTTP/2 staje się elementem ,które istnieje i działa ale fizycznie nie daje satysfakcji na którą liczy klient.

Jestem zwolennikiem lekkich stron z większym i mniejszym sukcesem ale doszukuje się w tych nowych rozwiązaniach ukrycia podstawowego problemu jakim jest brak świadomości użytkowników że zwalanie winy na usługodawcę bo coś działa wolno niekoniecznie jest z jego winy.

Odnośnik do komentarza
Udostępnij na innych stronach

Pisząc że nie jest tak kolorowo właśnie miałem na myśli wszelkiego rodzaju testy przez użytkowników/klientów. Oczekiwania to jedno a realna wydajność to już inna sprawa ,która jak sam napisałeś przestaje mieć dodatnią wartość gdy witryna/projekt wymaga optymalizacji. Również dobrze że użyłeś określenia teoria. Pagespeed od google też był super hiper a wyszło tak że rozwój projektu gdzieś umyka obecnym oczekiwaniom. Pomimo wielu rodzajów/typów serwerów web dalej nie jest rozwiązana główna kwestia jaką jest sama witryna i jest składniki, sam to również zaznaczyłeś kategoryzując role w formie usługodawca -> usługa -> klient i jego witryna. Teoria jest taka by składowe elementy jak najszybciej dodarły do przeglądarki użytkownika. Super, ale co gdy tak się nie dzieje? Rozwiązanie typu HTTP/2 staje się elementem ,które istnieje i działa ale fizycznie nie daje satysfakcji na którą liczy klient.
Jestem zwolennikiem lekkich stron z większym i mniejszym sukcesem ale doszukuje się w tych nowych rozwiązaniach ukrycia podstawowego problemu jakim jest brak świadomości użytkowników że zwalanie winy na usługodawcę bo coś działa wolno niekoniecznie jest z jego winy.
Ano tak to już jest z oczekiwaniami. Nie dalej jak kilka dni temu też było pytanie: ile razy hosting na dyskach ssd jest szybszy od tego zwykłego. Nigdy nie wiem co w takim przypadku odpowiedzieć ;-)
Odnośnik do komentarza
Udostępnij na innych stronach

27 minut temu, smarthost napisał:
1 godzinę temu, SiXwishlist napisał:
Pisząc że nie jest tak kolorowo właśnie miałem na myśli wszelkiego rodzaju testy przez użytkowników/klientów. Oczekiwania to jedno a realna wydajność to już inna sprawa ,która jak sam napisałeś przestaje mieć dodatnią wartość gdy witryna/projekt wymaga optymalizacji. Również dobrze że użyłeś określenia teoria. Pagespeed od google też był super hiper a wyszło tak że rozwój projektu gdzieś umyka obecnym oczekiwaniom. Pomimo wielu rodzajów/typów serwerów web dalej nie jest rozwiązana główna kwestia jaką jest sama witryna i jest składniki, sam to również zaznaczyłeś kategoryzując role w formie usługodawca -> usługa -> klient i jego witryna. Teoria jest taka by składowe elementy jak najszybciej dodarły do przeglądarki użytkownika. Super, ale co gdy tak się nie dzieje? Rozwiązanie typu HTTP/2 staje się elementem ,które istnieje i działa ale fizycznie nie daje satysfakcji na którą liczy klient.
Jestem zwolennikiem lekkich stron z większym i mniejszym sukcesem ale doszukuje się w tych nowych rozwiązaniach ukrycia podstawowego problemu jakim jest brak świadomości użytkowników że zwalanie winy na usługodawcę bo coś działa wolno niekoniecznie jest z jego winy.

Ano tak to już jest z oczekiwaniami. Nie dalej jak kilka dni temu też było pytanie: ile razy hosting na dyskach ssd jest szybszy od tego zwykłego. Nigdy nie wiem co w takim przypadku odpowiedzieć ;-)

To są pytania z serii tych ciężkich i dziwnych ale poniekąd można to jakoś wyjaśnić gdy klient ma świadomość że serwer posiada dyski gdzie w jego świadomości dyski znaczy że dwa! A co powiedzieć kiedy tych dysków jest 18 i nie są to SSD a SAS?  

Odnośnik do komentarza
Udostępnij na innych stronach

Zyski z używania HTTP/2 są bezpośrednio połączone z ilością połączeń jaką musi wykonać klient, żeby załadować stronę.

 

Jeśli serwer zwraca jedynie czystego (może być przerobionego przez php) htmla, a wszystkie odnośniki wraz z cssami, javascriptami i innymi duperelami są np. na jakimś cdn, to zysku z używania HTTP/2 nie będzie żadnego lub będzie nawet ujemny w stosunku do połączenia HTTP/1.1.

 

Jednak w przypadku ładowania dużej ilości danych, przede wszystkim obrazków, cssy i innych dupereli, zysk może być rzeczywiście znaczący z powodu braku potrzeby ustanawiania nowego połączenia dla każdej pobieranej rzeczy. Ustanawianie połączenia, a już przede wszystkim szyfrowanego po HTTPS jest bardzo kosztowną operacją całkowicie niewspółmierną do np. pobrania malutkiego pliku css.

 

Inna sprawa to to, że na ogół wszystkie takie statyczne wieloelementowe rzeczy właśnie lądują na CDN, więc bardzo trudno będzie zauważyć rzeczywisty zysk. No chyba, że Twój klient ma wszystko hostowane na serwerze i nawet o CDN nie słyszał, ale wtedy to nie wiem o czym my w ogóle rozmawiamy.

Odnośnik do komentarza
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
 Udostępnij

  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Korzystając z forum, wyrażasz zgodę na: Warunki użytkowania, Regulamin, Polityka prywatności.