Wydajność HTTP/2

[smarthost]

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

[patrys]

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 12 Września 2017 przez patrys

[Mion]

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?

 

 

[behemoth]

My używamy Litespeeda, który natywnie wspiera http/2. Co do wydajności nie wypowiem się, nie testowałem przy wiekszym ruchu.
Więc Dariuszu, używać już można

[oui]

Jedną z najważniejszych cech h2 jest "push" który w nginxie jest wspierany tylko w pakiecie plus. Do tego dochodzi jeszcze to https://www.nginx.com/blog/supporting-http2-google-chrome-users/

[smarthost]

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

[bybunny]

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.

[smarthost]

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 

[bybunny]

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.

[smarthost]

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ć ;-)

[bybunny]

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?  

[gb1]

SSD nie może być SAS ? ;-)

[bybunny]

Może oczywiście ale miałem w tym konkretnym przypadku na myśli SAS na talerzach

[Archi]

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.