Как отслеживать накладные расходы, добавленные маршрутизацией запроса приложений?

Question

У нас есть служба SOAP Delphi, которая должна быть включена в SSL. Я решил использовать обратный прокси-сервер IIS ARR для разгрузки SSL для упрощения конфигурации (по сравнению с OpenSSL и ручным сертификатом + управление парольной фразой). ARR работает, но он добавляет безумное количество накладных расходов ... Время отклика прошло от менее чем от 2 секунд до 19 секунд за 18 запросов на обслуживание (около 60 Кб сжатого итога).

Я добавил журнал регистрации времени к клиенту & сервер, на который отправляются и принимаются сообщения. Он показывает примерно 1 секунду, добавляемую к каждой маршрутизации запроса через ARR между отправкой от клиента и получением службой. Ответ отсылается очень быстро, только маршрутизация запроса через ARR работает медленно (см. Изображение ниже).

Как я могу отслеживать источник накладных расходов? Является ли ARR не подходящим для этого варианта использования? Я попытался настроить и отключить большинство настроек, включая кеширование. Я пробовал разные хосты с чистыми настройками IIS, включая производственный Windows Server 2012. Сам SSL не является накладными расходами, просто наличие обратного прокси ARR HTTP вызывает задержку.

<?xml version="1.0" encoding="UTF-8"?> 
<configuration> 
    <system.webServer> 
     <rewrite> 
      <rules> 
       <rule name="ReverseProxyInboundRule1" stopProcessing="true"> 
        <match url="(.*)" /> 
        <action type="Rewrite" url="http://localhost:8987/{R:1}" /> 
       </rule> 
      </rules> 
     </rewrite> 
    </system.webServer> 
</configuration> 

Запрос & Образцы ответа от Скрипаче:

• Raw HTTP Request
• Raw HTTP Response

Answer 1

Мой совет: используйте IIS для приложений, используйте Apache HTTP Daemon для проксирования.

В прошлом я использовал различные компоненты программного и аппаратного обеспечения для разгрузки SSL (начиная где-то в 2003 году, я думаю). Каждый со своим собственным уровнем цен и функциями. В последние годы я перешел на использование Apache HTTP Daemon для этой цели. Даже в сочетании с IIS и Windows. Apache легко настраивается после того, как у вас есть работающий образец и более легко перерастает в более сложные сценарии с пересылкой и переименованием.

Некоторые инструкции по использованию HTTP-демона Apache для Windows в качестве механизма разгрузки SSL можно найти на http://www.invantive.com/about-invantive/news/entryid/897/ssl-offloading-for-apache-tomcat.

Answer 2

Я бы сказал, что у вас есть что-то вялое в вашей настройке. В настоящее время мы запускаем ARR для разгрузки SSL и проводим тестирование пропускной способности при значительном объеме, и ARR практически не влияет на пропускную способность.

Я согласен с Броком и сначала попробую проверить настройки своего приложения. В принципе, пул приложений ARR должен быть настроен так, чтобы никогда не перерабатывать.

Я бы рекомендовал смотреть эпизоды 32-38, начиная с: http://dotnetslackers.com/articles/iis/Bindings-and-Rules-for-Application-Request-Routing-ARR-Week-32.aspx

Answer 3

У нас такая же проблема. Я нашел корень, это в System.Net.Sockets.Socket.DoConnect Проблема связана с IPv6:

https://social.msdn.microsoft.com/Forums/vstudio/en-US/203b6230-e4c0-477c-9a0a-0c21a7ad1615/strange-onesecond-delay-with-tcpconnections-to-localhost?forum=clr

http://msdn.microsoft.com/en-us/library/115ytk56.aspx

«Если IPv6 включен и TcpClient (String, Int32) вызывается метод, чтобы подключиться к серверу, который решает как к IPv6 и IPv4, подключение к IPv6-адресу будет предпринято сначала перед адресом IPv4. Это может привести к задержке времени установления соединения, если хост не прослушивает адрес IPv6 ».

Чтобы разрешить его для запросов закольцованных вам нужно отключить IPv6 на машине см p.4-5-6: https://stackoverflow.com/a/12403731

Answer 4

Отключение IPv6, а Дмитрий предложил, решить это для меня.

Вы также можете использовать 127.0.0.1 в своем переписании вместо локального хоста, чтобы заставить IPv4.