ASMX Web Service langsam erste Anfrage

Habe ich einen Haufen .NET Webservices laufen in einem IIS-Anwendung. Diese webservices konsumiert werden, von einem anderen IIS-Anwendung (frontend). Der erste Aufruf ist sehr langsam, etwa 5 bis 10 Sekunden. Nach, dass es nur Millisekunden. Der erste Aufruf wird als ein performance-problem.

Wir haben versucht, eine Anwendung, die Anrufe, all diese webservices, aber dies natürlich nicht lösen, nichts. Es ist also nicht die Standard-Anwendung-Recycling, das ist das problem. Ich habe eine Anwendung erstellt, die nur initialisiert den Dienst mehrere Male und misst die Zeit, die es braucht, um erstellen Sie eine Instanz. Vor dem ausführen dieser Anwendung, die ich sicher, dass mein webservice-Anwendung gestartet wird /Recycling, dann habe ich die Anwendung ausführen. Die erste Initialisierung dauert zwischen 2 bis 4 Sekunden, alles andere ist nur Millisekunden.

Ein weiterer Gedanke ist, dass wir eine Seite erstellen in der Frontend-Applikation, welche alle webservices und wir rufen Sie diese Seite vor dem Benutzer befinden. Ich denke nicht, dass dies als eine elegante Lösung, was könnte ich sonst versuchen?

InformationsquelleAutor der Frage Remco Eissing | 2009-04-24

34

Die Verzögerung, die erlebt wird, wenn ein client ruft einen webservice für die erste Zeit wird durch die Tatsache verursacht, dass standardmäßig eine XmlSerializers dll für den webservice kompiliert werden muss. Dies verursacht die 2-4 Sekunden für den ersten Aufruf. Dies ist natürlich der Fall, wenn der webservice-Anwendung bereits ausgeführt wird, wenn es nicht, würden Sie haben einen Papierkorb. In dem Fall die anderen Antworten helfen konnte.

Zu beschleunigen, den ersten Anruf können Sie erstellen, die XmlSerializers dll zu kompilieren. Sie können dies tun, indem Sie das Projekt erstellen 'Generieren Serialisierungs-assembly' auf. Dies erzeugt eine MyApplication.XmlSerializers.dll mit der webservice-Informationen. Nun der erste Aufruf fiel auf 300 ms, vermutlich das laden der dll. Alle Anrufe nach 0 ms.

In Visual Studio mit der rechten Maustaste auf Ihr Projekt und wählen Sie "Eigenschaften". Gehen Sie auf die "Erstellen" - Registerkarte. Dort haben Sie die option 'Generieren Serialisierungs-assembly' in die 'Output-Abteilung'. Wenn Sie ändern Sie den Wert Auf 'an' die Serialisierungs-assembly generiert, die während der Kompilierung.

InformationsquelleAutor der Antwort Remco Eissing
9

Dem ersten Aufruf des webservice, oder das erste mal nach einer langen Verzögerung, die der web service braucht um zu starten. Dies ist, wo sehen Sie die Verzögerung. Danach, es ist bereits gestartet und reagiert wirklich schnell auf Anrufe. Dies ist die standard-web-service-Verhalten.

Könnten Sie konfigurieren IIS zu haben keepalive = true - das kann die Leistung verbessern.

Mehr Informationen, wie verlangt.

Könnte es sein, dass die Serialisierungs-assemblies werden zur Laufzeit angelegt. Sie können die Einstellungen ändern, die Serialisierungs-assembly mit Hilfe des dropdown-unten im Build-Bereich des Fenster "Eigenschaften" für das Projekt.

Könnte es sein, dass Sie geschrieben haben, Ihre web-service durchzuführen, eine Menge von Operationen auf Anwendung starten, was passieren würde, das erste mal eine Methode auf dem service aufgerufen wird.

Könnte es sein, dass die Bedienung sehr langsam, aber Sie sind dann das caching der Antwort, welche die spätere Anrufe schneller.

InformationsquelleAutor der Antwort user75525
5

Vor kurzem habe ich entdeckt, dass in unserer ASMX-Dateien, die von uns nur gemäß den Namen der Klasse. Wir haben die service-Implementierung in eine andere assembly für jede ASMX-Datei. Dies verursacht .NET framework-scan über den gesamten bin-Ordner suchen für die assembly mit der Umsetzung. Als Ihre webservice-Anwendung wächst diese verbrauchen mehr Zeit.
Dieses Problem kann gelöst werden, indem nicht nur darunter wird der name der Klasse in Ihre ASMX-definition, sondern auch den Namen der assembly.

Unserer ASMX sah so aus:

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

Wenn Sie es ändern, enthalten die Baugruppe mit der Umsetzung würde es so Aussehen. Das ersparte uns etwa 10% von unserem ersten laden der webservice-Anwendung.

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

InformationsquelleAutor der Antwort Remco Eissing
4

Typisch ist, da ASP.NET apps kompilieren und laden Sie die bin\ - Verzeichnis in den Speicher beim ersten Antrag.

Dinge zu tun, zuerst:

Entfernen Sie alle nicht benötigten dll ' s in dein bin-Verzeichnis. (Ich habe Leute gesehen, die Schiff nunit.dll)

Vorkompilieren ASP.NET app so, dass der IIS nicht benötigen. Siehe "VS 2008 Web Deployment Project Support Veröffentlicht"

InformationsquelleAutor der Antwort Chad Grant
2

Nicht sicher, ob dies zu lösen, wird langsam drehen bis der WS auf dem "ersten mal", wie ich angenommen, es gibt einen laden, kompilieren und die .net DLL ' s geladen werden, aber Sie können fast zu beseitigen, eine Zukunft kalt startet, indem Sie den Anwendungspool der WS ist richtig konfiguriert ist.

Standardmäßig IIS6 hat "respawn" bei Leerlauf nach einer bestimmten Anzahl von Minuten oder "recycle" - Veranstaltungen, die effektiv starten Sie den WS jedes mal. Wenn Ihr gerne den service stabil ist, dann sind diese nicht benötigt werden.

Sicherzustellen, dass die WS hat einen eigenen dedizierten Anwendungspool (ist nicht die Freigabe einer unangemessenen pool) ist auch eine starke Empfehlung.

InformationsquelleAutor der Antwort Guy
1

Nach mehreren Stunden von insane testing, ich war in der Lage zu reduzieren die webservice-first-run-Ausführung Zeit zu bloßen minimum von zwei Hosts im selben IP-Klasse (unten 300msec)....

Erlebte ich zunächst eine Verzögerung von 2-3 Sek auf den ersten webservice-Aufruf, als jeder nachfolgende Anruf von der gleichen Prozess sehr schnell.

Den Schlüssel für das Verständnis der Verzögerung in meinem Fall war, wie client übernimmt WEB-PROXY !!

Dies ist meine neue Bindung in der app.config-Datei:
```
  <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>
```
Den ersten webcall Ausführung ich nehme an, viel langsamer, weil der transport channel müssen zu entdecken-proxy-Konfiguration bei der Initialisierung, um die transparente Verbindung zum internet. Dies ist in der Regel nicht erforderlich, intranet-Umgebung, damit ich mich geändert habe, diese Bindung-Einstellungen zu vermeiden, verwenden Sie die Standard-proxy (automatisch erkannt aus dem explorer-Einstellungen):

bypassProxyOnLocal="false"

useDefaultWebProxy="false"

Die first-call-Verbindung Zeit ist jetzt reduziert, indem eine große Menge.
Hoffe, das hilft.

InformationsquelleAutor der Antwort Paolo Marani
0

Sorry für den necro hinzufügen, aber dies war ein kontinuierlicher Kampf für mich, und ich wollte fügen Sie einige Infos zu dem Bild. VisualStudio selbst fügt eine ziemlich große Komponente der Zeit. Hier ist die grundlegende Prüfung, die mit einem bare-bones-forms-Anwendung und einer bereits Laufenden webservice-intern gehostet auf einem server im Unternehmen (mit Generieren Serialisierungs-Assembly auf true festgelegt, die für alle tests):
```
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's .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
```
Kurze Geschichte? Visual Studio fügt eine großen Teil der Zeit auf das Bild. Statt ~90 ms, es dauert fast eine Sekunde. Also, wenn du tust, performance-tuning, stellen Sie sicher, dass Ihre Tests außerhalb der VisualStudio-Umgebung.

InformationsquelleAutor der Antwort Kevin

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.