Vor ein paar Monaten rief mich ein Geschäftsführer aus dem Maschinenbau an. Sein ERP-Zusatztool — eine ASP.NET-Webanwendung, intern entwickelt — "hängt manchmal". Seit Wochen. Das Entwicklerteam: zwei Personen, eine davon Teilzeit. Die erste Frage, die ich stellte: "Habt ihr Logging in Produktion?" Antwort: "Wir sehen die Fehlermeldungen im Browser."
Das war der Ausgangspunkt. Kein Monitoring, kein Profiling, kein Plan — nur die Aussage der Nutzer, dass es manchmal langsam ist. In solchen Momenten denke ich an die Werkzeugkisten, die Experten wie Steve Gordon im Regal haben, und frage mich: Wie viel davon ist hier eigentlich anwendbar?
Was Steve Gordon sagt
Steve Gordon — Microsoft MVP, .NET-Engineer bei Elastic, langjähriger Community-Sprecher — hat einen 60-minütigen Talk zur Praxis der Performance-Optimierung in .NET zusammengefasst. Der Kern: Performance ist nie irrelevant, aber blindes Optimieren ist genauso gefährlich wie Ignorieren. Sein Ansatz folgt einem klaren Zyklus: Monitoring in Produktion, Profiling mit dotTrace und dotMemory, Benchmarking mit BenchmarkDotNet, gezielte Verbesserungen bei Allokationen und Ausführungszeit — und das alles balanciert gegen Lesbarkeit und Wartbarkeit. An einem konkreten Arbeitsbeispiel zeigt er, wie eine Feature-Implementierung durch den vollständigen Optimierungszyklus geführt wird. Das ist solide Handwerksarbeit aus der Welt der .NET-Plattformingenieure.
Wie das im KMU landet
Jetzt kommt der Teil, den Gordon nicht zeigt — weil er ihn vermutlich nicht täglich sieht.
Was sofort funktioniert: Der konzeptuelle Rahmen — Monitoring vor Optimierung, messen statt raten — ist universell gültig, egal ob Du fünf oder fünfhundert Entwickler hast. In meinen Mandaten ist das der häufigste Fehler: Man optimiert auf Verdacht, weil jemand sagt "das fühlt sich langsam an". Gordons Botschaft "messe zuerst" ist keine .NET-Weisheit, das ist Handwerk.
BenchmarkDotNet ist außerdem zugänglicher als sein Ruf. Für isolierte Methoden, die Du verdächtigst, lässt sich ein Benchmark in 30 Minuten schreiben. Ich habe das in KMU-Projekten gemacht — nicht als kontinuierliche CI-Pipeline, sondern als Einmalmessung, wenn der Verdacht konkret war. Das skaliert auch mit kleinen Teams.
Was nicht direkt übertragbar ist: dotTrace und dotMemory sind JetBrains-Werkzeuge mit Lizenzkosten und einer Lernkurve. In einem Zwei-Personen-Entwicklerteam, das gerade versucht, ein Release rauszubringen, investiert niemand drei Tage in Profiling-Werkzeug-Einführung. Das ist keine Kritik an den Werkzeugen — die sind exzellent — sondern eine Ressourcen-Realität.
Dazu kommt: Gordon arbeitet in einer Umgebung, wo der Code unter Kontrolle ist. Im Mittelstand ist das oft nicht so. Ich habe Mandate erlebt, wo die Kernapplikation von einer externen Agentur entwickelt wurde und der Sourcecode zwar offiziell beim Kunden liegt, aber niemand wirklich weiß, was drin steckt. Profiling einer Black Box ist ein anderes Gespräch als Profiling von eigenem Code, den Du täglich siehst.
Was fehlt: Gordon setzt voraus, dass Du Monitoring in Produktion hast. Das ist die Prämisse seines gesamten Lifecycle-Ansatzes. Im Mittelstand ist das die Ausnahme, nicht die Regel. Ich schätze, dass in 70 Prozent der KMU-Betriebe, die ich erstmals besuche, keine strukturierte Logging- und Monitoring-Infrastruktur vorhanden ist. Kein Application Insights, kein Seq, kein Prometheus — nichts. Bevor ich über Allokationsoptimierung rede, muss ich dort über Grundausstattung reden.
Ein weiterer blinder Fleck: die Datenbankschicht. Performance-Probleme in KMU entstehen oft nicht durch schlechten Managed Code, sondern durch falsche Datenbankabfragen, fehlende Indizes oder eine ERP-Integration, die unbewusst alle fünf Sekunden einen Full Table Scan auslöst. Das ist kein .NET-Problem — das ist ein Architektur-Problem, das man mit dotTrace nicht findet, weil die Zeit im SQL-Server liegt, nicht im C#-Code.
Meine konkrete Empfehlung
Für ein KMU mit einer laufenden .NET-Anwendung und ersten Performance-Klagen würde ich folgendermaßen vorgehen:
Schritt 1 — Messen, bevor Du irgendetwas anfasst. Kein Werkzeug, kein Profiler. Nur strukturiertes Logging mit Timestamps. Wo verbringt die Anwendung ihre Zeit? Das beantwortet oft schon 80 Prozent der Fragen — und kostet nichts außer einem Nachmittag.
Schritt 2 — SQL vor .NET. In meiner Erfahrung liegt die Ursache in 60–70 Prozent der Fälle nicht im C#-Code, sondern in der Datenbankschicht. Slow Query Log einschalten, die Top-10-Abfragen analysieren — das kostet nichts und liefert fast immer Treffer.
Schritt 3 — Erst dann Profiling. Wenn Du weißt, dass das Problem im Managed Code liegt, ist dotTrace richtig. Aber dann weißt Du auch, welchen Teil Du profilen musst — und die Investition in das Werkzeug lohnt sich, weil Du nicht im Nebel stocherst.
Schritt 4 — BenchmarkDotNet für die verdächtige Methode. Nicht als Dauerbetrieb, sondern als Einmalmessung. Hat die Optimierung geholfen? Der Benchmark sagt ja oder nein, ohne Bauchgefühl.
Gordons Talk ist der beste Einstieg in Schritt 3 und 4. Für Schritt 1 und 2 brauchst Du andere Quellen — oder jemanden, der das schon ein paarmal gemacht hat.
Der vollständige Original-Beitrag von Steve Gordon: Talk: Application Performance Optimisation in Practice (60 mins)
Wenn Du gerade vor einer ähnlichen Situation stehst — Anwendung hängt, Team überfordert, keine Ahnung wo anfangen — dann buch Dir 30 Minuten:
Kein Verkaufsgespräch. Ich schaue mir Deine Situation an und sage Dir, wo ich anfangen würde.
— Bernhard