Schreckliche Leistung bei der Verwendung von SqlCommand-Async-Methoden

Auf einem system ohne große Last, einen asynchronen Aufruf hat einen etwas größeren Aufwand. Während die I/O-operation selbst ist asynchron, unabhängig, die Blockierung kann schneller sein als die thread-pool-Aufgabe wechseln.

Wie viel Aufwand? Let ' s look at Ihr timing zahlen. 30ms für einen blockierenden Aufruf, 450ms für einen asynchronen Aufruf. 32 kiB Paket-Größe bedeutet, dass Sie brauchen, die Sie brauchen etwa fünfzig einzelne I/O-Operationen. Das heißt, wir haben etwa 8ms von overhead auf jedes Paket, das entspricht ziemlich gut mit Ihren Messungen in verschiedenen Paketgrößen. Das klingt nicht overhead nur von asynchronen, auch wenn die asynchronen Versionen müssen tun viel mehr Arbeit als die synchrone. Es klingt wie die synchron-version ist (vereinfacht) 1 Anfrage -> 50 Antworten, während die asynchrone version endet als 1 Anfrage -> 1 Antwort -> 1 Anfrage -> 1 Antwort -> ..., die Zahlung der Kosten immer und immer wieder.

Tiefer gehen. ExecuteReader funktioniert genauso gut wie ExecuteReaderAsync. Die nächste operation ist Read gefolgt von einem GetFieldValue - und eine interessante Sache, die da passiert. Wenn eine der beiden ist async, der ganze Vorgang ist langsam. Also es ist sicherlich etwas, was sehr anderen geschieht, sobald Sie beginnen, die Dinge wirklich asynchron - eine Read schnell, und dann die async - GetFieldValueAsync wird langsam sein, oder Sie können beginnen mit dem langsamen ReadAsync, und dann beide GetFieldValue und GetFieldValueAsync sind schnell. Die ersten asynchronen Lesen aus dem stream ist langsam, und die Langsamkeit, hängt ganz von der Größe der gesamten Zeile. Wenn ich mehr Zeilen in der gleichen Größe, Lesen jeder Zeile nimmt die gleiche Menge an Zeit, als wenn ich nur eine Zeile, so ist es offensichtlich, dass die Daten ist noch gestreamt werden Zeile für Zeile - es scheint nur zu bevorzugen, um Lesen Sie die gesamte Zeile auf einmal, sobald Sie beginnen alle asynchrone Lesen. Wenn ich lese die erste Zeile asynchron, und die zweiten synchron - die zweite Zeile gelesen wird, dann wird schnell wieder.

So können wir sehen, dass das problem ist eine große Größe einer einzelnen Zeile und/oder Spalte. Es spielt keine Rolle, wie viele Daten Sie haben insgesamt Lesen eine million kleine Zeilen asynchron ist genau so schnell wie synchron. Aber fügen Sie nur ein einzelnes Feld zu groß, um zu passen in ein einziges Paket, und Sie auf mysteriöse Weise fallen Kosten an asynchron zu Lesen, dass die Daten - als wenn jedes Paket benötigt ein trennen-request-Paket und der server konnte nicht einfach senden Sie alle Daten auf einmal. Mit CommandBehaviour.SequentialAccess keine Verbesserung der performance, wie erwartet, aber die riesige Lücke zwischen sync und async ist noch vorhanden.

Die beste Leistung, die ich bekam war, wenn macht die ganze Sache richtig. Das bedeutet, dass mit CommandBehaviour.SequentialAccess sowie streaming der Daten explizit:

using (var reader = await cmd.ExecuteReaderAsync(CommandBehaviour.SequentialAccess))
{
  while (await reader.ReadAsync())
  {
    var data = await reader.GetTextReader(0).ReadToEndAsync();
  }
}

Mit dabei, der Unterschied zwischen sync und async wird schwer zu Messen, und die änderung der Paketgröße nicht mehr anfallen, die lächerlichen Aufwand als zuvor.

Wenn Sie möchten, eine gute Leistung in Rand-Fällen, stellen Sie sicher, dass Sie die besten verfügbaren Werkzeuge - in diesem Fall-stream große Spalte Daten, anstatt sich auf Helfer wie ExecuteScalar oder GetFieldValue.

InformationsquelleAutor Luaan