[ADO.NET] Statement-Laufzeiten ermitteln?

[Phoenix]

Jo, genau:

Wie kann ich bei einem ADO.NET Statement die Laufzeit des Statements messen, OHNE vor und hinter dem Execute jeweils einen Timestamp rauszuschreiben.

Am liebsten wäre es mir, nach dem Execute irgendwo die Laufzeit auszulesen.
Gibts sowas? Das müsste für normale Statements und Stored Procedures funktionieren.

[Bernhard Geyer]

Entweder AQTime nehmen oder im SQL Tracer-Tool die "Laufzeiten" mitprotokollieren.

[Phoenix]

Äh, die Lösung ist etwas unpraktisch, weil wir keinen direkten Zugriff auf das Live-System haben und die Infos im Prinzip hinterher in die Log-Tabelle schreiben müssen. Und bei unserem Testsystem ist die Performance 1A...

Das heisst ich muss die Laufzeiten aus der Anwendung heraus ermitteln und wegloggen können.

[Bernhard Geyer]

Dann mußt du es selbst machen wenn du eh mit deiner Logdatei was spezielles hast.
Hast du den den DB-Layer gekapselt so das du nur 2-3 "Einfallstore" für das Absetzen der SQL-Queries hast oder wurde der DB-Zugriff aufs Programm verstreut realisiert?

[Phoenix]

Leider letzteres. :cry:

Das Problem ist ja auch, dass das momentan einen derben Performance-Impact beim Kunden (Individualsoftware, die setzt nur dieser eine Kunde ein) hat. Hier läuft alles einwandfrei.

Ich tippe eh auf die Datenbank, weil die z.B. eine View haben, die bei uns auf der Entwicklungs-DB (1:1 Kopie des produktiven Datenbankfiles) ca. 200 MB Speicher zieht und nach 4-5 Sekunden angezeigt wird, beim Kunden katapultiert diese View den Datenbankserver an die Grenze des physikalisch verfügbaren Speichers (irgendwo ganz knapp unter 2 GB) und schmeisst eine OutOfMemory Exception. Und das nur, wenn auf ein spezielles Feld eingeschränkt wird. Relativ Strange das ganze, zumal unsere Entwicklungs-DB-VM nur 1 Gig Ram bekommt und auch sonst nicht so groß dimensioniert ist wie deren DB-Server.

Dort dauert das Ausliefern einer ASP.NET Seite ca. 30 Sekunden, bei uns ca. 1-2. Und jetzt müssen wir rausbekommen, warum dem dort so ist. Und da die sogar die Administration outgesourced haben fällt meine erste Idee (Spotlight on SQL Server während dem Betrieb dranhängen und gucken was geht) leider aus weil wir keinen Zugriff auf deren DB-Server haben :-(

[Bernhard Geyer]

Also ihr habt gar keinen Zugriff auf den SQL-Server - korrekt?
ist ja fast so als würde ich einen Mangel des Autos anmeckern aber dem Händler keine Chance geben das Auto Live zu sehen.

Ihr könntet es jetzt Hart auf Hart kommen lassen und sagen das ohne direkten Zugriff keine weitere Fehlereingrenzung möglich ist. Alle sonstigen Tests wurden ja durchgeführt. Evtl mit Rechtsanwalt abklären was ihr genau schreibt.

Wie wäre es denn ein Image des Systems zu bekommen. Evtl. sind ja irgendwelche Firewalls etc. aktiv die das Verursachen.

[Elvis]

Sicher dass beide DBs mit den gleichen Metadaten arbeiten? Hauptsächlich Spaltengrößen/-typen und Indizes wären interessant.

[Phoenix]

Naja.. das nervt den Kunden ja auch. Er würde uns ja liebend gerne dran lassen, aber da die den Server komplett Managed von HP haben und HP weder die selber noch uns dran lässt...

Wir wollen denen nix böses und die wollen uns ja auch nix böses.

Der Webserver und die Datenbank laufen auf dem gleichen System, von daher ist es eher unwahrscheinlich dass da was dazwischenhängt. Zumal das nicht alle Datenbankzugriffe betrifft: Downloads von Blobs die in der Datenbank gespeichert sind flutschen wie nochwas. Und die sind zum Teil bis zu 10 MB groß und sind superflott da (wie Filecopy im Netz).

Ich tippe auch eher darauf, dass bei denen noch ein paar Tabellen einen Schuss haben. Die angesprochene View läuft auf über 60 Joins, und das ist ein arg seltsames Verhalten bei denen, was hier ja absolut nicht nachvollziehbar ist. Das kann sich auch auf normale Tabellen auswirken, nur ohne genau zu wissen bei welchen Statements die DB hängt (hängt sie überhaupt?) kann ich das nur schlecht nachvollziehen. Aber ich werde jetzt wirklich vor und nach jedem Statement kurz einen Timestamp ablegen und als erstes im Page_Unload in die DB packen. Dann hat der User seine Seite schon und ich hoffentlich meine Performancedaten :)

[Bernhard Geyer]

Zitat:

Zitat von Phoenix

Naja.. das nervt den Kunden ja auch. Er würde uns ja liebend gerne dran lassen, aber da die den Server komplett Managed von HP haben und HP weder die selber noch uns dran lässt...

Das liebe Outsouring. Kenn schon genug Firmen die hier auch Böse auf die Schn... gefallen sind und das nach 1-2 Jahren wieder gekippt haben.

Zitat:

Zitat von Phoenix

Wir wollen denen nix böses und die wollen uns ja auch nix böses.

Wie wäre es den Spieß umzudrehen. Geht doch gemeinsam gegen HP los. Entweder sie lassen den Zugriff zu oder sie beheben das Problem selbst. Wenn nicht: Geldhahn zudrehen bzw. kürzen da Leistungen nicht erbracht werden. Es kann ja wohl nicht sein das die hier für teures Geld Däumchen drehen.

[Phoenix]

Das führt leider nicht zu einer schnellen Lösung. Und ich denke die sind eigentlich froh drum, dass HP das am laufen hält (mehr oder weniger - hauptsache sie haben sich nicht selber drum zu kümmern). Zudem ist ja auch noch gar nicht sicher, dass es überhaupt die DB ist. Das will ich ja erst nachgucken. Von daher denke ich, dass das erstmal passt. Und wenns dann doch an der DB liegt, dann können wir HP mit den Messungen auch gleich sagen: Schaut Euch mal das Laufzeitverhalten von der und der Abfrage / View / Storeproc an, da stimmt was nicht - und dann wissen die schonmal wo sie genau hingucken müssen und freuen sich auch über konkrete Hinweise.