Примерно, какой удар по производительности принесет https по сравнению с http для той же страницы? Предположим, я могу обработать 1000 запросов / с для abc.php, насколько он уменьшится при доступе через https? Я знаю, что это может зависеть от аппаратного обеспечения, конфигурации, ОС и т. Д., Но я просто ищу общее правило / оценка.
apache-2.2
performance
erotsppa
источник
источник
Ответы:
Для быстрого и грязного теста (т. Е. Без оптимизации!) Я включил простой веб-сайт Ubuntu apache2 по умолчанию (который просто говорит «Это работает!») С http и https (самозаверяющий сертификат) на локальной виртуальной машине Ubuntu 9.04 и запустил apache бенчмарк "
ab" с 10 000 запросов (без параллелизма). Клиент и сервер находились на одной машине / виртуальной машине:Результаты для http ("
ab -n 10000 http://ubuntu904/index.html")Результаты для https ("
ab -n 10000 https://ubuntu904/index.html"):Если вы внимательно посмотрите (например, с помощью tcpdump или wireshark) на связь tcp / ip одного запроса, вы увидите, что для случая http требуется 10 пакетов между клиентом и сервером, тогда как https требует 16: задержка намного выше с https. (Подробнее о важности латентности здесь )
Добавление keep-alive (
abопция-k) в тест улучшает ситуацию, потому что теперь все запросы используют одно и то же соединение, т. Е. Накладные расходы SSL ниже, но https по-прежнему измерим медленнее:Результаты для http с keep-alive ("
ab -k -n 10000 http://ubuntu904/index.html")Результаты для https с keep-alive ("
ab -k -n 10000 https://ubuntu904/index.html"):Вывод :
источник
На современных серверах я бы сказал, что узким местом будет сеть и ваше приложение, а не шифрование. TLS / SSL в apache будет написан на довольно оптимизированном C, поэтому ваш PHP-код будет затмевать, особенно если вы собираетесь делать такие вещи, как доступ к базе данных. Обслуживание статических файлов, вероятно, окажет большее влияние, так как шифрование станет большей частью всего процесса. Я не могу дать вам никаких конкретных цифр, но я был бы удивлен, если бы это было больше 5% и, вероятно, ближе к паре процентов.
источник
Ничего не предполагай, попробуй сам! На ваших конкретных веб-приложениях, конечно.
источник
Я обнаружил, что на современном оборудовании у меня больше шансов быть привязанным к конкретной транзакции для ввода-вывода, чем для процессора (вычислений). Это особенно верно, когда речь идет о сжатии и шифровании. 128-битное шифрование в наши дни тривиально - я, как правило, сталкиваюсь с гораздо более сложным построением и доставкой исходящих страниц, чем с использованием SSL, и не заметил значительной разницы в производительности между трафиком http и https в течение нескольких лет.
источник
Я второй рекомендации для Nginx. В моих собственных тестах, он выдержал как выделенный загрузчик SSL.
источник
Конечно, если обработка SSL сильно ударила, вы всегда можете перенести ее с сервера в специальный ящик. Существует хороший подправить делать это с Nginx над здесь . Это то, что мы сделали на высоконагруженных серверах уровня 7 с балансировкой нагрузки.
источник
Я могу подтвердить, что добавленная нагрузка для шифрования очень мала по сравнению с любым другим включенным элементом (скриптинг, сеть, ...)
источник
Из моего опыта общее правило напрямую связано с тем, насколько велик ваш открытый ключ (например, 2048, против 4096, против 8192) - все занимает значительно больше времени. Однако я вряд ли могу заметить разницу в среде рабочего стола, но мобильность - это то, где вы видите разницу, поскольку она требует вычислительной мощности.
В целом, это неудачно, но SSL всегда и, скорее всего, всегда будет сильно портить производительность.
источник