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

У нас есть служба Delphi SOAP, для которой необходимо включить 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>

Примеры запросов и ответов от Fiddler:


iis iis-7 soap arr iis-arr
person carlmon    schedule 12.11.2013    source источник
comment
Не должно быть такой задержки. Первое, что приходит на ум, - это настройка тайм-аута пула приложений, они закрываются, а задержка - запуск пула при каждом запросе? Убедитесь, что они никогда не отключаются из-за простоя.   -  person Brock Hensley    schedule 16.11.2013
comment
@dirt спасибо за ответ. Отключение моего пула приложений в режиме ожидания установлено на два дня и перерабатывается только при нарушении лимита использования памяти. В настоящее время я работаю без управляемого кода и интегрированного конвейера. Трассировка IIS показывает, что задержка связана с EXECUTE_REQUEST_HANDLER ARR (я добавил изображение после вашего комментария).   -  person carlmon    schedule 16.11.2013
comment
@carlmon Просто интересно, решали ли вы это когда-нибудь? Я подозреваю производительность ARR в моей среде (хотя в этом нет ничего плохого), ps: я вижу, что ARR 3.0 только что вышел из бета-версии.   -  person CameraSchoolDropout    schedule 04.12.2013
comment
Нет решения. Это все ARR 3.0. Мы выпустили без SSL и, вероятно, будем использовать OpenSSL в Delphi в нашем следующем обновлении для поддержки SSL.   -  person carlmon    schedule 06.12.2013
comment
Изменение localhost на 127.0.0.1 в URL-адресе перезаписи действия значительно сократило время загрузки.   -  person Raghav    schedule 29.08.2019

Ответы (4)


arrow_upward
9
arrow_downward

У нас такая же проблема. Я нашел рут, он в 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 на компьютере, см. Стр. 4-5-6: https://stackoverflow.com/a/12403731

person Dmitry Gorbunov    schedule 15.12.2014
comment
Вместо отключения ipv6 я использовал 127.0.0.1, поэтому он подключается к ipv4 и получает ожидаемое время ответа. - person Joost Aarts; 16.09.2016

arrow_upward
4
arrow_downward

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

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

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

person Guido Leenders    schedule 18.11.2013
comment
Спасибо, Гвидо, но у меня нет контроля над средами развертывания, что ограничивает меня либо обратным прокси-сервером IIS, либо ручным использованием OpenSSL в моем процессе Delphi (что является проблемой). Я действительно использую разгрузку SSL Apache для других сайтов, и это прекрасно работает. - person carlmon; 19.11.2013
comment
Привет, хорошо, я понимаю, это довольно сложно, по крайней мере, в прошлом. Удачи! - person Guido Leenders; 20.11.2013

arrow_upward
1
arrow_downward

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

Вы также можете использовать 127.0.0.1 в своей перезаписи вместо localhost для принудительного использования IPv4.

person Steve Desmond    schedule 23.08.2015
comment
Спасибо за отзыв, но вы должны указать это, отметив правильный ответ Дмитрия и удалив этот ответ. - person Rob Grant; 04.08.2016
comment
Спасибо за отзыв, но я не был оригинальным постером. Я уже поддержал ответ Дмитрия, но я также предложил альтернативное решение :) - person Steve Desmond; 05.08.2016
comment
извините, я, должно быть, теряю его! - person Rob Grant; 05.08.2016

arrow_upward
0
arrow_downward

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

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

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

person mvandiest    schedule 20.10.2014