Z grubsza, ile uderzenia wydajności zajmie https w porównaniu do http dla tej samej strony? Załóżmy, że mogę obsłużyć 1000 żądań / s dla abc.php, o ile to zmniejszy się, gdy uzyskasz dostęp przez https? Wiem, że może to zależeć od sprzętu, konfiguracji, systemu operacyjnego itp., Ale szukam tylko ogólnej zasady.
apache-2.2
performance
erotsppa
źródło
źródło
Odpowiedzi:
Dla szybkiego i brudnego testu (tj. Bez jakiejkolwiek optymalizacji!) Włączyłem prostą domyślną stronę Ubuntu apache2 (która mówi tylko „działa!”) Zarówno z http, jak i https (certyfikat z podpisem własnym) na lokalnej maszynie wirtualnej Ubuntu 9.04 i uruchomiłem apache test porównawczy „
ab” z 10 000 żądań (bez współbieżności). Klient i serwer znajdowały się na tej samej maszynie / maszynie wirtualnej:Wyniki dla http („
ab -n 10000 http://ubuntu904/index.html”)Wyniki dla https („
ab -n 10000 https://ubuntu904/index.html”):Jeśli przyjrzysz się bliżej (np. Za pomocą tcpdump lub wireshark) komunikacji tcp / ip pojedynczego żądania , zobaczysz, że przypadek http wymaga 10 pakietów między klientem a serwerem, podczas gdy https wymaga 16: Opóźnienie jest znacznie większe w przypadku https. (Więcej o znaczeniu opóźnienia tutaj )
Dodanie testu aktywności (
abopcja-k) poprawia sytuację, ponieważ teraz wszystkie żądania korzystają z tego samego połączenia, tj. Obciążenie SSL jest niższe - ale https jest nadal mierzalny wolniej:Wyniki dla http with keep-alive („
ab -k -n 10000 http://ubuntu904/index.html”)Wyniki dla https z keep-alive („
ab -k -n 10000 https://ubuntu904/index.html”):Wniosek :
źródło
Na nowoczesnych serwerach powiedziałbym, że twoim wąskim gardłem będzie sieć i twoja aplikacja, a nie szyfrowanie. TLS / SSL w Apache będzie napisany w dość zoptymalizowanym C, więc będzie mniejszy od twojego kodu PHP, zwłaszcza jeśli będziesz robił takie rzeczy jak dostęp do bazy danych. Udostępnianie plików statycznych prawdopodobnie będzie miało większy wpływ, ponieważ szyfrowanie stanie się większą częścią całego procesu. Nie mogę podać żadnych konkretnych liczb, ale byłbym zaskoczony, gdyby było to więcej niż 5% i prawdopodobnie kilka procent bliżej.
źródło
Nic nie zakładaj, sprawdź to sam! Oczywiście w konkretnych aplikacjach internetowych.
źródło
Uważam, że na nowoczesnym sprzęcie bardziej prawdopodobne jest, że będę związany operacją wejścia / wyjścia dla określonej transakcji niż procesorem (obliczeniem). Jest to szczególnie prawdziwe, gdy mówimy o kompresji i szyfrowaniu. 128-bitowe szyfrowanie jest obecnie trywialne - generalnie trafia mnie znacznie trudniejsze budowanie i dostarczanie stron wychodzących niż przez SSL, i od kilku lat nie zauważyłem znaczącej różnicy w wydajności między ruchem HTTP i https.
źródło
Drugie zalecenie dla nginx. W moich własnych testach zachowywał się dobrze jako dedykowany odciążający SSL.
źródło
Oczywiście, jeśli przetwarzanie SSL mocno uderzy, zawsze możesz przenieść je poza serwer do dedykowanego pola. Jest miły napisać w ten sposób z nginx ponad tutaj . Jest to coś, co zrobiliśmy na wysoce obciążonych serwerach z równoważeniem obciążenia warstwy 7.
źródło
Mogę potwierdzić, że dodatkowe obciążenie związane z szyfrowaniem jest bardzo małe w porównaniu z każdym innym dołączonym elementem (skrypty, sieć, ...)
źródło
Z mojego doświadczenia wynika, że ogólna zasada jest bezpośrednio związana z tym, jak duży jest twój klucz publiczny (np. 2048, w porównaniu z 4096, w porównaniu z 8192), wszystko zajmuje znacznie dłużej. Jednak prawie nie zauważam różnicy w środowisku Desktop, ale mobilność jest tam, gdzie widzisz różnicę, ponieważ wymaga mocy obliczeniowej.
Zasadniczo jest to niefortunne, ale SSL zawsze i najprawdopodobniej zawsze będzie pociągał za sobą wysoką wydajność.
źródło