Hallo zusammen und danke fürs Lesen,
Ich habe ein Verzögerungsproblem, da meine Anwendung lange braucht, um zu starten, wenn sie nach einer bestimmten Zeitspanne seit dem letzten Aufruf zum ersten Mal aufgerufen wird. Die Webanwendung ist ein WCF-Dienst und wir sprechen von einer Verzögerung von ~18 Sekunden, bevor die eigentliche Verarbeitung beginnt. Nun, ich glaube, ich weiß, wie ich diese Verzögerung reduzieren kann, also ist das nicht meine Frage (es ist sowieso eher ein Stackoverflow-Problem).
Meine Frage istKann mir jemand erklären, warum die Anwendung trotz der Deaktivierung der Funktionen zum Herunterfahren und Wiederverwenden von Arbeitsprozessen nach einer unbestimmten Zeit der Inaktivität immer noch „heruntergefahren“ wird?
Um dies zu verstehen, muss ich mehr über die Funktionsweise von WCF-Diensten wissen, die in IIS gehostet werden. Ich gehe fest davon aus, dass es darauf eine einfache Antwort gibt.
Vielen Dank für Ihre Hilfe, DC
Antwort1
Wenn auf der Registerkarte „Recycling und Leistung“ des Arbeitsprozesses alles deaktiviert ist, sollte IIS die Prozesse nicht beenden. Gibt es Ereignisprotokolleinträge, die der Zeit entsprechen, zu der der Prozess „heruntergefahren“ ist? Für mich klingt das so, als ob die WCF-App möglicherweise abstürzt. WCF protokolliert keine Ausnahmen im Ereignisprotokoll wie eine Standard-.NET-App. Wenn Sie also keine eigenen Protokolle schreiben, sollten Sie Folgendes aktivieren:WCF-Ablaufverfolgungum zu sehen, ob das vielleicht das Problem ist.
Die schnelle, hässliche Lösung für Ihr Problem könnte in der Zwischenzeit darin bestehen, eine Art kostengünstige Test- oder schreibgeschützte Transaktion in Ihrem WCF-Dienst zu erstellen und einfach eine Überwachungs-App oder ein Überwachungsskript so zu konfigurieren, dass es alle X Sekunden eine Abfrage ausführt, um den Arbeitsprozess mit dem vorab per JIT erstellten Code am Leben zu erhalten.
Antwort2
Ich glaube, das Problem hatte nichts mit WCF zu tun und der Fehler lag bei nHibernate, das seine Zuordnungen sortierte. Ich habe es gelöst, indem ich die nHibernate-Zuordnungsdateien kompiliert habe, sodass nHibernate dies nicht tun musste.