Weird Timeout Probleme mit Dapper.net

8

Ich habe dapper.net aus Performancegründen vor einiger Zeit benutzt und ich mag die benannte Parameter Funktion im Vergleich zu "ExecuteQuery" in LINQ To SQL.

Es funktioniert gut für die meisten Abfragen, aber ich bekomme von Zeit zu Zeit einige wirklich seltsame Timeouts. Das Seltsamste ist, dass dieses Timeout nur auftritt, wenn das SQL über Dapper ausgeführt wird. Wenn ich die ausgeführte Abfrage, die vom Profiler kopiert wurde, nehme und sie einfach in Management Studio laufe, ist sie schnell und funktioniert perfekt. Und es ist nicht nur ein vorübergehendes Problem. Der Query-Timeout per Dapper ist konsistent und funktioniert in Management Studio konsistent.

%Vor%

Das ist die Abfrage, die ich aus SQL Profiler kopiert habe. Ich führe es so in meinem Code aus.

%Vor%

Ich habe keine Ahnung, wo ich hier anfangen soll. Ich nehme an, es muss etwas mit Dapper passieren, da es gut funktioniert, wenn ich nur den Code ausführe.

Wie Sie in diesem Screenshot sehen können. Dies ist die gleiche Abfrage, die zuerst über Code und dann über Management Studio ausgeführt wird.

Ich kann auch hinzufügen, dass dies nur passiert (ich denke), wenn ich zwei oder mehr Wörter habe oder wenn ich ein "Stopp" -Zeichen in der Suchzeichenkette habe. Es kann also etwas mit der Volltextsuche haben, aber ich kann nicht herausfinden, wie es zu debuggen ist, da es perfekt von Management Studio funktioniert.

Und um das Ganze noch schlimmer zu machen, funktioniert es auf meinem localhost mit einer fast identischen Datenbank sowohl aus dem Code als auch aus Management Studio.

    
Olaj 28.03.2013, 13:29
quelle

3 Antworten

7

Dapper ist nichts anderes als ein Dienstprogramm Wrapper über ado.net; Es ändert nichts an der Funktionsweise von ado.net. Es klingt für mich, dass das Problem hier ist "arbeitet in ssms, scheitert in ado.net". Dies ist nicht einzigartig: Es ist ziemlich üblich, dies gelegentlich zu finden. Wahrscheinliche Kandidaten:

  • "set" -Option: diese haben unterschiedliche Standardeinstellungen in ado.net - und können die Performance beeinflussen, insbesondere wenn Sie Dinge wie "berechnet" + "beibehalten" + indizierte Spalten haben - wenn die "set" -Optionen nicht kompatibel sind, kann sie entscheiden t verwende den gespeicherten Wert, also nicht den Index - und stattdessen table-scan und recompute. Es gibt andere ähnliche Szenarien.
  • Systemlast / Transaktionsisolationslevel / Blockierung; etwas in ssms auszuführen, reproduziert nicht die gesamte Systemlast zu diesem Zeitpunkt
  • zwischengespeicherte Abfragepläne: manchmal wird ein duff-Plan zwischengespeichert und verwendet; Das Ausführen von SSMs erzwingt normalerweise einen neuen Plan - der natürlich auf die Parameter abgestimmt ist, die Sie in Ihrem Test verwenden. Aktualisieren Sie alle Ihre Indexstatistiken usw., und überlegen Sie, ob Sie den Abfrage-Hinweis "optimieren für"
  • hinzufügen
Marc Gravell 29.03.2013, 09:42
quelle
6

In ADO ist der Standardwert für CommandTimeout 30 Sekunden in Management Studio infinity. Passen Sie das Befehlszeitlimit für den Aufruf von Query & lt; & gt; an, siehe unten.

%Vor%

Siehe auch SqlCommand.CommandTimeout-Eigenschaft auf MSDN

    
Georg 11.09.2015 13:15
quelle
1

Es könnte eine Frage sein, das Befehls-Timeout in Dapper zu setzen. Hier ist ein Beispiel, wie Sie das Befehls-Timeout in Dapper anpassen können: Festlegen des Befehlstimeouts in Dapper

    
Jamie 28.03.2013 13:41
quelle