Медлительность SSL в EC2

Question

Мы развернули наше приложение rails на EC2. В нашей настройке у нас есть два прокси в небольших случаях за циклическим DNS. Они запускают балансировщики нагрузки nginx для динамично растущей и сокращающейся фермы веб-серверов. Каждый веб-сервер также запускает nginx с кластером дворняжек. Здесь nginx заботится о статическом контенте и балансировке нагрузки для помесей.

Так или иначе, наш трафик в целом - HTTPS. У нас есть 2 прокси, заботящиеся о SSL. Я заметил, что пропускная способность нашей сети в этих случаях составляет всего 60 Мбит / с или около того. Для сравнения, в тестировании я могу последовательно получать 700+ Мбит / с на небольшом экземпляре через обычный HTTP. Фактически, это то же самое, что я могу получить на большом экземпляре. Подобно тому, что ребята из Right Scale получили в тестировании . (Amazon говорит, что малый получает «умеренный» сетевой ввод-вывод, а большой - «высокий». Если бы мне пришлось размышлять, я думаю, что это всего лишь их способ сказать, что на один физический блок приходится больше маленьких экземпляров, совместно использующих одну сетевую карту Я не уверен, означает ли это, что большой получает выделенный сетевой интерфейс, но я бы сомневался в этом.)

В ходе тестирования мне удалось получить большой экземпляр для получения SSL 250 Мбит / с. Это говорит мне о том, что узким местом является процессор или какой-либо другой ресурс. Тем не менее, наши графики мониторинга не показывают, что процессор на наших прокси-серверах особенно загружен.

Мои вопросы:

1. Мой инстинкт о том, что SSL работает медленнее из-за правильной загрузки процессора и неправильных графиков мониторинга? Или какой-то другой ресурс может быть ограничивающим фактором?
2. Должны ли мы просто взять дополнительную плату и поставить прокси на экземпляры с высоким процессором? Или лучше добавить больше маленьких экземпляров?
3. Должны ли мы разгрузить SSL-терминацию на веб-серверы? Это создает еще одну проблему: как получить IP-адрес клиента в нашем приложении? Прямо сейчас наш прокси устанавливает его в заголовке X-FORWARDED-FOR, но, очевидно, это было бы невозможно, если бы он не расшифровывал SSL.

Я бы хотел услышать о любых подобных настройках. Мы немного повозились с их Elastic Load Balancer, но я думаю, что это в основном ставит нас в ту же ситуацию, что и № 3 выше. Кто-нибудь еще сделал переход на ELB и нашел, что оно того стоит?

Answer 1

Используете ли вы кеш сеанса SSL, который предоставляет nginx? Это может помочь nginx сэкономить на циклах, постоянно перерабатывая шифрование. Смотри http://wiki.nginx.org/NginxHttpSslModule#ssl_session_cache

Какой мониторинг вы используете для определения использования вашего процессора? SSL обычно сильно загружает процессор.

Я бы оставил прокси-серверы SSL в качестве назначенного уровня, чтобы вы могли масштабировать стоимость согласования ssl отдельно от других проблем.

Answer 2

Я использую SSL на Apache, который обрабатывает доступ к нашему хранилищу Subversion в экземпляре Small Windows EC2. В ходе тестирования я обнаружил, что доступ HTTPS был немного медленнее, чем HTTP, но это по очевидной причине, что шифрование / дешифрование не является мгновенным процессом, как вы ожидаете.

Если показатели вашего процессора правильные и вы не видите чрезмерной нагрузки, то это означает, что пропускная способность является ограничивающим фактором; однако я действительно не понимаю, почему вы можете получить скорость 700+ Мбит / с на экземпляре HTTP, по сравнению с 60 Мбит / с на экземпляре HTTPS. Если, конечно, условия теста не были идентичны, конечно, и внутри экземпляра HTTPS происходит что-то еще, что вы не учитывали ...

Конечно, более крупные экземпляры получают лучшую долю пропускной способности хоста, чем Smalls - их меньше, конкурирующих за ресурс. Поскольку внутренняя сеть EC2 - это Gigabit Ethernet, можно увидеть скорость 700 Мбит / с на большом экземпляре, если предположить, что другие крупные экземпляры на том же узле не предъявляли аналогичных требований к пропускной способности. Чтобы извлечь это из Small экземпляра, вам действительно повезло, что вы работали на очень легко загруженном хосте. И в этом случае не будет никакой гарантии, что вы сохраните этот уровень производительности - как только другие Smalls подключатся к сети, ваша доля доступной пропускной способности начнет падать.

Я думаю, что это, по сути, проблема пропускной способности малого экземпляра - добавление большего количества Smalls не обязательно сильно поможет, потому что вы не можете контролировать, на каком хосте они раскручиваются; Большие экземпляры, тем не менее, получают больший кусок пирога пропускной способности и, следовательно, могут иметь более стабильную доступность емкости.

Answer 3

SSL медленнее: - true, тогда любой нормальный HTTP-запрос HTTPSSL будет медленнее.

Попробуйте создать аналогичную настройку в локальной сети, где у вас есть 3 mongrel_clust и 2 веб-сервера. и проверьте с помощью curl loader, отправив около 5 тыс. запросов.

если все в порядке, это здорово. возможно, вы будете усерднее работать с ребятами из EC2.