Что может вызвать двухминутную задержку вызова веб-службы?

Question

У нас есть приложение .NET 3.5, которое вызывает веб-сервис на сервере. Почти в каждой установке этого приложения весь процесс запроса / ответа занимает около половины секунды.

В одной конкретной установке эти запросы таинственно занимают почти ровно 85 секунд (в течение полсекунды).

Моей первой мыслью было, что клиент веб-сервиса перестраивает сборку XML-сериализации при каждом вызове, но даже прямая отправка жестко закодированного XML-файла по-прежнему занимает почти одинаковое время. Наблюдение за сетевым трафиком, кажется, указывает на то, что фактическая отправка данных в транзакции происходит менее чем за секунду. Так что проблема все на стороне клиента.

Есть ли какая-то задержка разрешений, которая может быть причиной этой проблемы?

Редактировать (более подробно):
Приложение представляет собой базовую оболочку для запросов веб-службы - введите некоторые параметры, отправьте запрос веб-службе и получите ответ. Мы начали с клиентского кода, сгенерированного инструментом wsdl.exe, но также попытались напрямую использовать HttpWebRequest, когда столкнулись с проблемами. Из следующих журналов и сетевых трассировок поток выглядит так:

T 0:00 - user initiates request
T 1:24 - the application sends request to server
T 1:25 - the client receives the response and displays to the user.

Answer 1

Спасибо за все ваши предложения. Проблема была вызвана автоматическим определением прокси. По сути, если Internet Explorer настроен на автоматическое обнаружение прокси, то HttpWebRequest также будет работать, только он будет автоматически обнаруживаться каждый раз, когда вы создаете новый WebRequest, вместо того, чтобы что-либо кэшировать полезным способом.

В конце концов я нашел эту статью KB: http://support.microsoft.com/kb/968699

Решением было просто добавить это в файл app.config:

<configuration>
    <system.net>
        <defaultProxy >
            <!-- Disable Autoproxy-->
            <proxy autoDetect="false"/>
        </defaultProxy>
    </system.net>
</configuration> 

Answer 2

Звучит как проблема тайм-аута. Одна мысль - какой тип прокси настроен? Машина пытается обнаружить HTTP-прокси, прежде чем она сделает запрос? Я думаю, что пришло время использовать сетевой монитор, чтобы увидеть, что происходит.

Answer 3

Если данные отправляются менее чем за секунду, но общее время ответа составляет 85 секунд, почему вы чувствуете, что проблема на стороне клиента? Требуется ли 85 секунд для получения ответа от сервера?

Как правило, если вы видите такой тип очень постоянной (в течение полсекунды) задержки, найдите какой-то тайм-аут в вашей обработке. Это очень похоже на тайм-аут сети. Есть ли сетевой ресурс, к которому сервер может пытаться получить доступ? Аутентификация является одним из таких сетевых ресурсов. Общий файловый ресурс, внешний вызов http или ftp также могут быть кандидатами.

Можете ли вы описать вашу заявку более подробно?

Answer 4

Используйте такую ​​программу, как wireshark, чтобы прослушивать сеть при выполнении запроса. Сначала на клиенте, и если вы все еще в темноте на сервере. (оба в то же время дают еще больше понимания).

Таким образом, вы можете исключить повторные передачи tcp-ip, проблемы аутентификации, странности прокси и т. Д.

Answer 5

Если сервис также .NET, вы можете определить источник проблемы с помощью трассировки. Вы можете добавить следы в ваш файл web.config следующим образом:

 <system.diagnostics>
        <sources>
            <source name="System.ServiceModel"
                    switchValue="Information, ActivityTracing"
                    propagateActivity="true">
                <listeners>
                    <add name="traceListener"
                        type="System.Diagnostics.TextWriterTraceListener"
                        initializeData="c:\temp\Traces.txt"  />
                </listeners>
            </source>
        </sources>
    </system.diagnostics>

Это отследит любую активность System.ServiceModel, которая является веб-сервисом в 3.5