Подтвердить что ты не робот

Первый запрос ASMX Web Service

У меня есть куча .NET Webservices, работающая в одном приложении IIS. Эти веб-сервисы используются другим приложением IIS (интерфейс). Первый вызов довольно медленный, около 5-10 секунд. После этого его просто миллисекунды. Первый вызов считается проблемой производительности.

Weve попробовал приложение, которое вызывает все эти веб-службы, но это, очевидно, ничего не решает. Таким образом, это не утилита Application Recycle по умолчанию. Я создал приложение, которое просто инициализирует службу несколько раз и измеряет время, необходимое для создания одного экземпляра. Перед запуском этого приложения я гарантирую, что мое приложение webservice запущено/переработано, затем я запустил приложение. Первая инициализация занимает от 2 до 4 секунд, остальные - всего миллисекунды.

Еще одна мысль состоит в том, что мы создаем страницу в приложении Frontend, которая инициирует все веб-службы, и мы вызываем эту страницу до того, как будут какие-либо пользователи. Я не считаю это элегантным решением, что еще я могу попробовать?

4b9b3361

ОТВЕТЫ

Ответ 1

Задержка, которая возникает, когда клиент вызывает веб-сервис в первый раз, вызвана тем, что по умолчанию необходимо скомпилировать dll XmlSerializers для веб-службы. Это вызывает 2-4 секунды для первоначального вызова. Конечно, это тот случай, когда приложение webservice уже запущено, если оно не будет иметь рециркуляцию. В этом случае другие ответы могут помочь.

Чтобы ускорить первоначальный вызов, вы можете создать dll XmlSerializers во время компиляции. Это можно сделать, установив сборку проекта "Генерировать сборку сериализации" на. Это создает файл MyApplication.XmlSerializers.dll, содержащий информацию о веб-сервисе. Теперь начальный вызов упал до 300 мс, предположительно, загрузка DLL. Все вызовы там после принимают 0 мс.

В Visual Studio щелкните правой кнопкой мыши по вашему проекту и выберите "Свойства". Перейдите на вкладку "Создать". Там у вас есть опция "Создать сборку сборки" в разделе "Выход". Если вы измените значение на 'On', сборка будет генерироваться во время компиляции.

Ответ 2

При первом вызове веб-службы или в первый раз после долгой задержки веб-служба должна запускаться. Здесь вы видите задержку. После этого он уже начался и будет быстро реагировать на вызовы. Это стандартное поведение веб-службы.

Вы можете настроить IIS на keepalive = true - что может повысить производительность.

Дополнительная информация по запросу.

Может быть, сборки сборки сериализации создаются во время выполнения. Вы можете изменить настройки сериализации, используя раскрывающийся список внизу панели "Сборка" окна свойств для проекта.

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

Возможно, операция очень медленная, но вы затем кешируете ответ, что ускоряет последующие вызовы.

Ответ 3

Недавно я обнаружил, что в наших ASMX файлах мы ссылались только на имя класса. Мы получили реализацию сервиса в другой сборке для каждого ASMX файла. Это заставляет платформу .NET сканировать всю папку bin в поисках сборки, содержащей реализацию. По мере роста вашего приложения для веб-сервисов это потребует больше времени. Это можно решить, не только включая имя класса в определении ASMX, но также и имя сборки.

Наш ASMX выглядел так:

<%@ WebService Language="C#" CodeBehind="MyService.cs" Class="MyWebservice" %>

Если вы измените его, включив сборку, содержащую реализацию, она будет выглядеть так. Это спасло нас примерно на 10% от нашей начальной загрузки приложения webservice.

<%@ WebService Language="C#" CodeBehind="MyService.cs" Class="MyWebservice, MyWebservice.Implementation.Assembly" %>

Ответ 4

Это типично, поскольку приложения ASP.NET компилируют и загружают каталог bin\в память при первом запросе.

Что делать первым:

Удалите всю ненужную dll в каталоге bin. (Я видел, как люди отправляют nunit.dll)

Предварительно скопируйте приложение ASP.NET, чтобы IIS не нуждался. См. " Выпущена поддержка проекта развертывания VS 2008

Ответ 5

Не уверен, что это решит медленное разворот WS в "самый первый раз", так как я предполагаю, что загружается загружаемая компиляция и .net DLL, но вы можете почти ликвидировать любые будущие холодные запуски, обеспечивая пул приложений, в котором находится WS, настроен правильно.

По умолчанию IIS6 имеет "респаун" на холостом ходу, через несколько минут или "перезаписывать" события, которые каждый раз эффективно перезапускают WS. Если ваш счастливый сервис стабилен, тогда они не нужны.

Обеспечение того, что у WS есть собственный выделенный пул приложений (не используется неприемлемый пул), также является сильной рекомендацией.

Ответ 6

После нескольких часов безумного тестирования я смог сократить время выполнения первого запуска webservice до минимума с двух хостов в том же классе IP (ниже 300 мс)....

Сначала я испытал начальную задержку в 2-3 секунды при первом вызове webservice, чем любой последующий вызов из того же процесса, чтобы быть очень быстрым.

Ключом к пониманию задержки в моем случае было то, как клиент обрабатывает WEB PROXY!!

Это моя новая привязка в файле app.config:

  <basicHttpBinding>
    <binding name="CreateContextSoap" closeTimeout="00:01:00" openTimeout="00:01:00"
        receiveTimeout="01:00:00" sendTimeout="01:00:00" allowCookies="false"
        bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
        maxBufferSize="16777216" maxBufferPoolSize="524288" maxReceivedMessageSize="16777216"
        messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
        useDefaultWebProxy="false">
      <readerQuotas maxDepth="32" maxStringContentLength="1048576" maxArrayLength="16384"
          maxBytesPerRead="65536" maxNameTableCharCount="16384" />
      <security mode="None">
        <transport clientCredentialType="None" proxyCredentialType="None"
            realm="" />
        <message clientCredentialType="UserName" algorithmSuite="Default" />
      </security>
    </binding>
  </basicHttpBinding>

Первое выполнение веб-камеры, я предполагаю, что это намного медленнее, потому что транспортному каналу необходимо обнаружить конфигурацию прокси-сервера при инициализации, чтобы прозрачно подключаться к Интернету. Это обычно не требуется в среде интрасети, поэтому я изменил эти параметры привязки, чтобы избежать использования прокси-сервера по умолчанию (автоматически обнаруженного из настроек проводника):

bypassProxyOnLocal = "ложь"

useDefaultWebProxy = "ложь"

Время соединения первого вызова теперь уменьшается на большую сумму. Надеюсь, это поможет.

Ответ 7

Извините за добавление necro, но это продолжалось и для меня, и я хотел добавить некоторую информацию к картине. VisualStudio сам по себе добавляет довольно большой компонент. Здесь базовый тест, включающий приложение форм голой кости и уже запущенный веб-сервис, размещенный внутри компании на корпоративном сервере (с установкой Generate Serialization Assembly, равной true для всех тестов):

Running in VS, Debug:
    First Call: 400 ms to set up client object, 450 to call function
    Second Call: 1 ms to set up client object, 14 to call function
Running as .exe, Release:
    First Call: 20 ms to set up client object, 70 to call function
    Second call: 1 ms to set up client object, 4 to call function
Running the Debug .exe file outside of vs:
    First Call: 20 ms to set up client object, 80 to call function
    Second call: 1 ms to set up client object, 4 to call function
Running as Release within VS:
    Similar results to Debug in VS -- very slow

Рассказ? Visual Studio добавляет большое количество времени на изображение. Вместо ~ 90 мс он занимает почти секунду. Поэтому, если вы выполняете настройку производительности, убедитесь, что вы проводите тестирование вне среды VisualStudio.