wake-up-neo.com

Wie wird das Entity Framework "aufgewärmt"? Wann wird es "kalt"?

Nein, die Antwort auf meine zweite Frage ist nicht der Winter.

Vorwort:

Ich habe in letzter Zeit viel über Entity Framework geforscht, und etwas, das mich immer wieder stört, ist die Leistung, wenn die Abfragen nicht aufgewärmt sind, sogenannte kalte Abfragen.

Ich habe den Artikel Überlegungen zur Leistung für Entity Framework 5.0 durchgearbeitet. Die Autoren stellten das Konzept von warmen und kalten Abfragen vor und wie sie sich unterscheiden , was mir auch selbst aufgefallen ist, ohne von ihrer Existenz zu wissen. Hier ist es wahrscheinlich erwähnenswert, dass ich hinter meinem Rücken nur sechs Monate Erfahrung habe.

Jetzt weiß ich, zu welchen Themen ich zusätzlich recherchieren kann, wenn ich das Framework in Bezug auf die Leistung besser verstehen möchte. Leider sind die meisten Informationen im Internet veraltet oder voller Subjektivität, daher kann ich keine zusätzlichen Informationen zum Thema Warm vs Kalt finden.

Grundsätzlich ist mir bisher aufgefallen, dass meine ersten Abfragen immer dann sehr langsam werden, wenn ich neu kompilieren oder die Recycling-Treffer erzielen muss. Alle nachfolgenden Datenlesevorgänge sind erwartungsgemäß schnell ( subjektiv).

Wir werden auf Windows Server 2012, IIS8 und SQL Server 2012 migrieren und als Junior habe ich mir die Gelegenheit erarbeitet, sie vor dem Rest zu testen. Ich bin sehr froh, dass sie ein Aufwärmmodul eingeführt haben, das meine Bewerbung auf diese erste Anfrage vorbereitet. Ich bin mir jedoch nicht sicher, wie ich mit dem Aufwärmen meines Entity Framework fortfahren soll.

Was ich bereits weiß, lohnt sich:

  • Generieren Sie meine Ansichten im Voraus wie vorgeschlagen.
  • Verschieben Sie meine Modelle schließlich in eine separate Baugruppe.

Was ich mit gesundem Menschenverstand tun möchte , ist wahrscheinlich ein falscher Ansatz :

  • Durchführung von Dummy-Datenlesevorgängen beim Anwendungsstart, um die Modelle aufzuwärmen, zu generieren und zu validieren.

Fragen:

  • Was wäre der beste Weg, um jederzeit eine hohe Verfügbarkeit in meinem Entity Framework zu erreichen?
  • In welchen Fällen wird das Entity Framework wieder "kalt"? (Neukompilierung, Recycling, IIS Neustart usw.)
118
Peter
  • Was wäre der beste Weg, um jederzeit eine hohe Verfügbarkeit in meinem Entity Framework zu erreichen?

Sie können zwischen vorgenerierten Ansichten und statisch kompilierten Abfragen wählen.

Statisch CompiledQuerys sind gut, weil sie schnell und einfach zu schreiben sind und zur Leistungssteigerung beitragen. Mit EF5 ist es jedoch nicht erforderlich, alle Ihre Abfragen zu kompilieren, da EF die Abfragen automatisch kompiliert. Das einzige Problem ist, dass diese Abfragen verloren gehen können, wenn der Cache geleert wird. Sie möchten also weiterhin Verweise auf Ihre selbst erstellten Abfragen für diejenigen aufbewahren, die nur sehr selten auftreten, aber teuer sind. Wenn Sie diese Abfragen in statische Klassen einfügen, werden sie kompiliert, wenn sie zum ersten Mal benötigt werden. Für einige Abfragen ist dies möglicherweise zu spät. Daher möchten Sie möglicherweise die Kompilierung dieser Abfragen beim Start der Anwendung erzwingen.

Das Erstellen von Ansichten ist die andere Möglichkeit, die Sie erwähnen. Insbesondere für solche Abfragen, deren Kompilierung sehr lange dauert und die sich nicht ändern. Auf diese Weise verschieben Sie den Performance-Overhead von der Laufzeit zur Kompilierungszeit. Auch dies wird keine Verzögerung einführen. Aber diese Änderung wirkt sich natürlich auf die Datenbank aus, sodass es nicht so einfach ist, damit umzugehen. Code ist flexibler.

Verwenden Sie nicht viel TPT-Vererbung (dies ist ein allgemeines Leistungsproblem in EF). Bauen Sie Ihre Vererbungshierarchien weder zu tief noch zu breit auf. Nur 2-3 Eigenschaften, die für eine bestimmte Klasse spezifisch sind, reichen möglicherweise nicht aus, um einen eigenen Typ zu erfordern, können jedoch als optionale (nullfähige) Eigenschaften für einen vorhandenen Typ behandelt werden.

Halte dich nicht lange an einem einzigen Kontext fest. Jede Kontextinstanz verfügt über einen eigenen Cache der ersten Ebene, der die Leistung verlangsamt, wenn sie größer wird. Die Erstellung von Kontexten ist billig, aber die Statusverwaltung in den zwischengespeicherten Entitäten des Kontexts kann teuer werden. Die anderen Caches (Abfrageplan und Metadaten) werden zwischen den Kontexten geteilt und gehen zusammen mit der AppDomain verloren.

Alles in allem sollten Sie darauf achten, Kontexte häufig zuzuweisen und nur für kurze Zeit zu verwenden, dass Sie Ihre Anwendung schnell starten können, dass Sie selten verwendete Abfragen kompilieren und vorgenerierte Ansichten für leistungskritische und häufig verwendete Abfragen bereitstellen.

  • In welchen Fällen wird das Entity Framework wieder "kalt"? (Neukompilierung, Recycling, IIS Neustart usw.)

Grundsätzlich jedes Mal, wenn Sie Ihre AppDomain verlieren. IIS führt alle 29 Stunden Neustarts durch, sodass Sie niemals garantieren können, dass Ihre Instanzen verfügbar sind. Auch nach einiger Zeit ohne Aktivität wird die AppDomain heruntergefahren. Sie sollten versuchen, das Programm schnell wieder zu starten. Möglicherweise können Sie die Initialisierung asynchron durchführen (achten Sie jedoch auf Multithreading-Probleme.) Sie können geplante Tasks verwenden, die in Ihrer Anwendung Dummy-Seiten aufrufen, wenn keine Anforderungen zum Verhindern von auftreten AppDomain vor dem Sterben, aber es wird schließlich.

Ich gehe auch davon aus, dass beim Ändern der Konfigurationsdatei oder der Assemblys ein Neustart erfolgt.

55
Andreas

Wenn Sie bei allen Aufrufen maximale Leistung erzielen möchten, sollten Sie Ihre Architektur sorgfältig prüfen. Beispielsweise kann es sinnvoll sein, häufig verwendete Suchvorgänge im Server RAM beim Laden der Anwendung vorab zwischenzuspeichern, anstatt bei jeder Anforderung Datenbankaufrufe zu verwenden. Diese Technik gewährleistet minimale Antwortzeiten für die Anwendung Für häufig verwendete Daten: Sie müssen jedoch sicherstellen, dass die Ablaufrichtlinien korrekt sind, oder Sie müssen immer den Cache leeren, wenn Änderungen vorgenommen werden, die sich auf die zwischengespeicherten Daten auswirken, um Probleme mit der Parallelität zu vermeiden.

Im Allgemeinen sollten Sie sich bemühen, verteilte Architekturen zu entwerfen, die nur dann IO) - basierte Datenanforderungen erfordern, wenn die lokal zwischengespeicherten Informationen veraltet sind oder transaktionell sein müssen Das Abrufen dauert 10-1000-mal länger als das Abrufen eines lokalen Cache-Speichers. Allein aufgrund dieser Tatsache sind Diskussionen über "kalte vs. warme Daten" im Vergleich zum "lokalen vs. fernen" Datenproblem häufig ohne Belang.

9
mcstar

Allgemeine Hinweise.

  • Führen Sie eine strenge Protokollierung durch, einschließlich auf was zugegriffen wird und Anforderungszeit.
  • Führen Sie Dummy-Anforderungen aus, wenn Sie Ihre Anwendung für den Warmstart initialisieren sehr langsam Anforderungen, die Sie aus dem vorherigen Schritt abgerufen haben.
  • Optimieren Sie nicht, es sei denn, es handelt sich um ein echtes Problem. Kommunizieren Sie mit dem Benutzer der Anwendung und fragen Sie. Machen Sie es sich mit einer kontinuierlichen Rückkopplungsschleife bequem, wenn Sie nur was muss optimiert werden herausfinden möchten.

Nun erklären wir, warum Dummy-Anfragen nicht der falsche Ansatz sind.

  • Weniger Komplexität - Sie wärmen die Anwendung auf eine Weise auf, die unabhängig von Änderungen im Framework funktioniert, und Sie müssen keine möglicherweise funky APIs/Framework-Interna herausfinden, um dies zu tun = der richtige Weg.
  • Größere Abdeckung - Sie wärmen alle Ebenen des Cachings auf einmal auf, die mit der langsamen Anforderung zusammenhängen.

Um zu erklären, wann ein Cache "kalt" wird.

Dies geschieht in jeder Ebene in Ihrem Framework, die einen Cache anwendet. Eine gute Beschreibung finden Sie im oben auf der Leistungsseite .

  • Wann immer ein Cache nach einer möglichen Änderung validiert werden muss, die den Cache veraltet macht, kann dies eine Zeitüberschreitung oder eine intelligentere sein (d. H. Eine Änderung des zwischengespeicherten Elements).
  • Wenn ein Cache-Element entfernt wird, wird der Algorithmus dazu im Abschnitt "Cache-Entfernungsalgorithmus" in dem von Ihnen verknüpften Leistungsartikel beschrieben, jedoch in Kurzform.
    • LFRU (Least frequent - recent used) Cache bei Trefferanzahl und Alter mit einem Limit von 800 Items.

Die anderen Dinge, die Sie erwähnt haben, insbesondere das Neukompilieren und Neustarten von IIS löschen entweder Teile oder alle im Speicher befindlichen Caches.

8
udoprog

Verwenden Sie, wie Sie bereits gesagt haben, "vorgenerierte Ansichten", das ist wirklich alles, was Sie tun müssen.

Auszug aus Ihrem Link : "Wenn Ansichten generiert werden, werden sie auch validiert. Unter dem Gesichtspunkt der Leistung besteht der größte Teil der Kosten für die Generierung von Ansichten in der Validierung der Ansichten."

Dies bedeutet, dass die Leistungssteigerung beim Erstellen Ihrer Modellbaugruppe erfolgt. Ihr Kontextobjekt überspringt dann die "kalte Abfrage" und bleibt für die Dauer des Lebenszyklus des Kontextobjekts sowie nachfolgender neuer Objektkontexte ansprechbar.

Das Ausführen irrelevanter Abfragen dient keinem anderen Zweck als dem Verbrauch von Systemressourcen.

Die Abkürzung ...

  1. Überspringen Sie die zusätzliche Arbeit mit vorgenerierten Ansichten
  2. Erstellen Sie Ihren Objektkontext
  3. Löse diese süße irrelevante Frage aus
  4. Behalten Sie dann für die Dauer Ihres Prozesses einen Verweis auf Ihren Objektkontext (nicht empfohlen).
3
hotpie

Ich habe keine Erfahrung in diesem Rahmen. In anderen Zusammenhängen, z. Solr, vollständig Dummy-Lesevorgänge werden nur von Nutzen sein, wenn Sie die gesamte Datenbank (oder den gesamten Index) zwischenspeichern können.

Ein besserer Ansatz wäre, die Abfragen zu protokollieren, die häufigsten aus den Protokollen zu extrahieren und sie zum Aufwärmen zu verwenden. Stellen Sie lediglich sicher, dass Sie die Aufwärmabfragen nicht protokollieren oder aus den Protokollen entfernen, bevor Sie fortfahren.

2
estani