Erlang YAWS https налог
Поскольку все должно быть https, я включил его и заметил, насколько медленнее https по сравнению с http.
У меня есть сервер Ubuntu/YAWS в Далласе. Я запускаю YAWS используя "yaws --daemon --nodebug"
Если я сделаю
время скручивания -i https://share.spreadsheetconverter.com/echo/
а также
время скручивания -i http://share.spreadsheetconverter.com/echo/
от самого сервера https занимает около 100 мс, а http 20 мс, т.е. разница составляет 80 мс.
Когда мы пытаемся из Швеции, Европы, https составляет 1400 мс, а http 350 мс. Эти цифры могут быть логичными из-за латентности над Атлантикой.
Впрочем, теперь о странной вещи.
У меня также есть сервер Windows / IIS в Далласе.
Если я сравниваю простой запрос http-get на обоих серверах, то разница для https-штрафа гораздо больше для сервера YAWS, чем для IIS. (Я также протестировал Tomcat, и он ведет себя подобно IIS).
Это также зависит от времени ожидания, т. Е. Чем длиннее сервер, тем больше разница между IIS и YAWS.
Когда я делаю аналогичные тесты с сервером IIS в Далласе, из Швеции, https составляет 1000 мс, а http такой же, как для YAWS, т.е. IIS намного быстрее (400 мс) при https, чем Yaws. Как будто YAWS делает дополнительный сетевой вызов.
Я также экспериментировал с
и просто извлек время SSL, сообщенное ими. Обратите внимание, что время SSL увеличивается быстрее для YAWS
| YAWS | IIS
Dallas | 79ms | 75ms
New York | 212ms | 87ms
Amsterdam | 503ms | 315ms
Хорошо, что мне делать?
- Есть ли ошибка в моей настройке YAWS?
- Решит ли проблема размещение NGINX перед YAWS и позволит Nginx обрабатывать https?
- Есть ли ошибка в моем сертификате SSL? Могут ли они быть быстрее или медленнее? Я проверил с https://www.ssllabs.com/ssltest/analyze.html
Обновление 2015-08-20
Я обновился до версии 2.0, и да, разница в производительности все еще есть.
Используя
curl -v --trace-time --trace-ascii echo.log https://share.spreadsheetconverter.com/echo/
и сравнивая это с
curl -v --trace-time --trace-ascii server1.log https://www.spreadsheetserver.com/server1/
Я сравнил все ряды, я вижу, что мы теряем 300 мс в одном ряду.
Вот как это выглядит, когда мы говорим с Yaws 2.0
17:37:54.606668 == Info: TLSv1.2, TLS handshake, Finished (20):
17:37:54.606692 => Send SSL data, 16 bytes (0x10)
0000: ......Jb.9...#.^
17:37:54.758726 == Info: TLSv1.2, TLS change cipher, Client hello (1):
17:37:54.758761 <= Recv SSL data, 1 bytes (0x1)
0000: .
17:37:55.107695 == Info: TLSv1.2, TLS handshake, Finished (20):
17:37:55.107726 <= Recv SSL data, 16 bytes (0x10)
0000: ..........Y.xV.!
17:37:55.107784 == Info: SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA
и это когда я разговариваю с IIS
17:40:25.247308 == Info: TLSv1.0, TLS handshake, Finished (20):
17:40:25.247329 => Send SSL data, 16 bytes (0x10)
0000: ........f4..qh:(
17:40:25.376893 == Info: TLSv1.0, TLS change cipher, Client hello (1):
17:40:25.376925 <= Recv SSL data, 1 bytes (0x1)
0000: .
17:40:25.377081 == Info: TLSv1.0, TLS handshake, Finished (20):
17:40:25.377103 <= Recv SSL data, 16 bytes (0x10)
0000: ....C..'.A,..'R.
17:40:25.377142 == Info: SSL connection using TLSv1.0 / AES128-SHA
И для Yaws, и для IIS первая "Отправка данных SSL" занимает 150 мс
Для IIS два немедленных "Recv SSL data" следует без задержки.
Однако в случае с Yaws нам нужно подождать 350 мсек для первых "Recv SSL data", а затем следующий немедленно
Это как что-то асинхронное в IIS, но синхронизируется в Yaws. В IIS данные, которые должны быть получены, объединяются с подтверждением отправки, но в Yaws это два отдельных запроса.
Все эти запросы должны пройти через Атлантический океан. Если я вместо этого сделаю это с тем же центром обработки данных, различия будут намного меньше.
1 ответ
Nginx или HAproxy могут решить эту проблему. Вы должны прекратить ваш HTTPS-трафик на прокси-узле. И после этого вы должны передать HTTP-трафик на узел erlang. Более того, хранить эрланг-узел в интернете без прокси не очень хорошая практика.