[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.

[f.siebler]

hi,
um welche Version vom SQL Server handelt es sich? Ist es die Express Variante? Wenn ja könnte die Beschränkung auf max 1 GB Speicher das Problem erzeugen (Im Taskmanager ist zu sehen das er mehr belegt, klappt aber trotzdem nicht :-) )
Ansonsten könntest du über einen Trigger den Zugriff in eine Log Tabelle schreiben, z.b. vorher nacher Timestamp etc..
Noch eine gute möglichkeit wäre die Abfrage einfach mal in einer SP laufen zu lassen, dort hast du auch ohne direkten zugriff die möglichkeit das ganze in kleinere Schritte aufzuteilen... und vll. das Problem so zu beheben.
Und zu guter letzt noch ein Punkt, welche Speicherwerte sind für den Server eingestellt? Wie viel Speicher ist im zugewiesen? Wie viel darf er dynamisch dazuholen etc. mit den Server "SP's" wie Info und Help stehen dir die Daten zur Verfügung.

[shmia]

Also ich meine, das Performanceproblem lässt nur dann lösen,
wenn ein Vollbackup der Kundendatenbank gemacht wird und du einen Restore auf deinem SQL Server machst.
Der Kunde hat eine Mitwirkungspflicht und muss dir Informationen zur Fehlersuche geben.
Das schliesst auch Outsourcing Firmen ein.

[f.siebler]

ich denke zuerst sollte man die Einstellungen im SQL Server prüfen, bei vielen Kunden hat der Admin keine Ahnung vom SQL Server und stellt kraut und rüben werte ein die alles sehr sehr langsam machen....

[Phoenix]

Erm.. das Problem liegt offensichtlich nicht am SQL-Server, wie ich gerade mit Erschrecken feststellen durfte.

Allein das Ausliefern einer stinknormalen ASPX-Seite die ein Menü (Toolbar - Fremdkomponente von Telerik) und eine Textbox besitzt, keine Daten aus der Datenbank abfragt (zumindest definitiv nicht beim ersten Aufruf) und gerendert ca. 18kb hat, benötigt vom Request bis zur Anzeige zwischen 16 und 20 Sekunden(!) :shock: . Hier lokal ist die instant da....

Eine Datei von 10 MB liefert der allerdings in 5 Minuten aus (~30 KB/s), was ich in Ordnung finde. Also die Leitung ist es auch nicht.

Ich denke das Problem ist also eher beim IIS / ASP.NET Workerprocess zu suchen, ergo werd ich mich da mal schlau machen.

[Bernhard Geyer]

Kannst Du ein kleines Beispiel zusammenstellen und auf der Webseite hochladen lassen.
Dies sollte doch mindestens in Bereich von HP fallen wenn der ASP.NET-Teil nicht richtig eingerichtet wurde. Außer der Outsouringvertrag wurde sehr zu lasten eures Kunden ausgeführt so das HP nur für HW-Defekte zuständig ist und sonst schön die Kohle abgreifen kann.

[Phoenix]

Leider nein. Naja, ich hab die Performance-Logs jetzt mal eingebaut, Kollege wird das morgen Deployen und dann mal gucken was die uns morgen für Zahlen ausspucken.

Vielleicht liegts ja doch irgendwie am Netz...

[Phoenix]

Okay.. die Zahlen sind da.. kein Seitenaufbau inkl. aller Statements dauert länger als 150 ms, und das war ein Ausreisser, die meisten Laufzeiten bewegen sich zwischen 30 und 40 ms.

Der Bottleneck ist definitiv die Netzwerkinfrastruktur - wenn wir beim Arbeiten mit dem Dienst die Netzwerkports beobachten sehen wir bei einem Zugriff aus dem lokalen Netz einen ca. 1,5 Mbit hohen Peak über 2~3 Sekunden, bei externem Zugriff einen drittel bis halb so hohen Peak über zum Teil bis zu 40 Sekunden.

Naja, mal gucken was wir da machen können...