2016-04-10 10 views
1

Ich habe ein Problem mit meiner Entity Framework-basierten Website, nachdem ich sie auf Microsoft Azure gehostet habe. Wenn innerhalb von 30 Minuten keine Anrufe beim Server eingegangen sind, reagiert der Server nicht mehr vollständig und gibt für alle Anfragen interne Serverfehler (500) zurück.Timeout für Entity Framework-Server

Dies war kein Problem, wenn ich die Website lokal betrieben habe (ich könnte es stundenlang laufen lassen, ohne dass etwas passiert) und es würde immer noch funktionieren, wenn ich wieder dazu komme. Ich habe es geschafft, das Problem zu beheben, indem ich eine Schleife durchführte, die den Server alle 15 Minuten anpingt, aber das ist offensichtlich keine gute Lösung; also meine Frage ist: Wo und wie kann ich die Verbindungseigenschaften für meinen Server konfigurieren, um zu verhindern, dass er bei Nichtbenutzung abstürzt?

Ich weiß sehr wenig über Verbindung Authentifizierung und ich habe keine Ahnung, wie Sie dies beheben, wenn der einzige Fehler, den ich bekomme, ist ein interner Serverfehler (der sagt mir nichts). Hier

ist der Code auf Github: https://github.com/synthc/UMD.git

+1

Ich habe dieses Problem nicht gesehen, aber ich frage mich, ob ein Arbeitsthread nach 30 Minuten Inaktivität recycelt wird. Behalten Sie Datenbankkontexte für lange Zeit? – Basic

+0

Nun, ich mache nichts, um meinen Db-Kontext neu zu initialisieren, also würde ich annehmen, dass es nie neu zugewiesen wird (ist das eine schlechte Sache?). – synthc

+0

Ich habe keine aktuellen Erfahrungen mit Azure, kann also nicht direkt kommentieren. In meinen MVC-Apps lebt der Kontext der Datenbank für die Lebensdauer der Anfrage. So kann ich beispielsweise Änderungen rückgängig machen, ohne mich um andere Anfragen kümmern zu müssen. Sehen Sie sich Unity an, um einen DBContext abzurufen. Es kann die Lebensdauer der Objekte für Sie übernehmen. Siehe http://StackOverflow.com/a/18264598/156755 – Basic

Antwort

1

Eine Reihe von Dingen in den Sinn kam, dass ich mit Ihnen teilen möchte - eine davon zeigte bereits von Basic aus.

Always On

Also zunächst aus - der Grund, warum es scheinen mag, dass Ihre Web-App ‚einschläft‘ ist aufgrund eines Features in Azure Web Apps, die ausgeschaltet werden kann:

Always On description

Sie können mehr über diese Funktion here lesen.

Ich vermute, dass etwas schief geht, während Sie versuchen, Ihre Web-App wieder hochzuladen, nämlich etwas mit Ihrer Datenbankverbindung - was die 500s verursacht.

Datacontext Lebensdauer Management

Also, in der Tat, als Grund darauf hingewiesen - ich würde empfehlen, Dependency Injection mit (DI) für Entity Framework (EF) Kontext in dem Controller. Dies gibt dem EF-Datenkontext die Lebensdauer einer einzelnen Anfrage, was den Kontext zum Eintreten in einen fehlerhaften Zustand stark reduziert.

Ninject war die DI-Container, die ich am häufigsten verwendet, und hier ist eine Zuschreibung von, wie das bekommen mit ASP.NET MVC zu arbeiten: http://www.davepaquette.com/archive/2013/03/27/managing-entity-framework-dbcontext-lifetime-in-asp-net-mvc.aspx

Entity Framework Ausführungsstrategie

Schließlich - EF bietet verschiedene Ausführungsstrategien für die Datenbank an. Und es bietet eine spezielle für Verbindungen auf Azure. Sie wollen in die Aktivierung der SqlAzureExecutionStrategy wie hier beschrieben suchen: https://msdn.microsoft.com/en-us/data/dn456835.aspx. Dies wird besser mit der vorübergehenden Fehlerbehandlung umgehen, die in der Cloud auftreten kann.

Ich bin mir ziemlich sicher, dass wenn Sie all dies verwenden - Sie sollten in Ordnung sein und Sie 500s sollte weg sein.

+0

Danke für die Antwort. Leider erlaubt es mir mein Azure-Abonnement nicht, Always On zu verwenden (ich möchte jetzt upgraden). Wie bei der Abhängigkeitsinjektion verwende ich Ninject bereits, um mein benutzerdefiniertes Repository an eine Schnittstelle zu binden, und dann injiziere ich das in meinen Controller. Dies sollte den DB-Kontext einmal pro Anfrage initialisieren, da er in meinem Repository initialisiert wird, oder? – synthc

+0

Der DI-Container wird so konfiguriert, dass er eine Lebenszeit (aka Scope) für die erstellten Instanzen anwendet. Informationen zu NInject finden Sie in der [Dokumentation zum Objektbereich] (https://github.com/ninject/ninject/wiki/ObjectScopes) und speziell [InRequestScope] (https://github.com/ninject/Ninject.Web.Common/wiki/InRequestScope) – Basic

+0

Das Aktivieren von Always On hat anscheinend funktioniert. Vielen Dank. – synthc