Filip Jacobi, freiberuflicher Business Central Entwickler← Zur Startseite

Business Central Performance optimieren

Business Central Performance optimieren

Wenn BC mit dem Wachstum nicht mehr mitkommt

Business Central zu langsam? Echte Ursachen finden — DB-Schleifen, überlastete Job Queues, fehlende Archivierung — und dauerhaft beheben. Festpreis-Diagnose.

Wenn BC mit jedem Monat langsamer wird

Viele Unternehmen kennen das Muster: Business Central hat beim Start gut funktioniert. Aber mit der Zeit — mehr Nutzer, mehr Daten, mehr Anpassungen — wird das System langsamer. Seiten brauchen mehrere Sekunden zum Laden. Reports am Monatsabschluss hängen sich auf. Der Jahresabschluss dauert statt zwei Stunden plötzlich einen halben Tag.

Der zuständige Partner sagt: Das ist normal bei dieser Datenmenge. Oder: Ihr braucht eine größere Azure-Instanz.

Beides kann stimmen. Meistens ist es aber keins von beidem — die echten Ursachen sind im Code und in der Konfiguration zu finden, nicht in der Infrastruktur.

Die häufigsten Performance-Ursachen in der Praxis

Nicht jede Performance-Verschlechterung hat dieselbe Wurzel. Die häufigsten Ursachen, die ich in Praxisprojekten sehe:

DB-Schleifen in Custom-Extensions sind die häufigste Ursache für plötzliche Performance-Einbrüche nach einem Extension-Update oder einer Neueinführung. Eine Codeunit, die für jeden Datensatz eine eigene Datenbankabfrage macht, statt eine mengenbasierte Abfrage zu nutzen — das skaliert nicht. Bei 100 Datensätzen ist es noch tolerabel. Bei 10.000 Datensätzen dauert derselbe Prozess 100-mal länger.

Nicht archivierte Transaktionsdaten sind der häufigste Langzeit-Killer. BC speichert standardmäßig alle Posten, Belegdaten und Protokolle unbegrenzt. Nach drei bis fünf Jahren prodiktiven Betriebs können einzelne Tabellen Millionen von Einträgen haben — und jede Abfrage muss durch diesen Berg. Richtig konfigurierte Retention Policies und Archivierungsläufe lösen dieses Problem ohne Datenverlust.

Überlastete Job Queue Entries verlangsamen das Gesamtsystem, wenn zu viele Hintergrundjobs gleichzeitig laufen oder schlecht priorisiert sind. Ein Job-Queue-Eintrag, der stündlich eine aufwändige Synchronisation startet, kann alle anderen Prozesse ausbremsen.

Synchrone externe API-Aufrufe im Transaktionspfad sind eine häufig übersehene Ursache: Wenn eine Extension bei jeder Buchung synchron eine externe API anfragt — zum Beispiel für Adressvalidierung oder Lagerbestand — und diese API auch mal langsam antwortet, wartet BC mit.

Fehlende oder falsche Schlüssel auf Custom-Tabellen führen dazu, dass Abfragen ohne Index-Unterstützung laufen. Bei kleinen Datenmengen nicht spürbar — bei großen Tabellen ein erhebliches Problem.

Was ich anbiete

Performance-Diagnose (Festpreis)

Ein klar umgrenzter Analyse-Auftrag: Ich schaue mir dein System systematisch an — AL-Code der Extensions, Datenbankstruktur, Job-Queue-Konfiguration, Slow-Query-Logs — und liefere dir ein Ergebnis in Form eines Befunds mit priorisierten Maßnahmen.

Du bekommst eine klare Antwort: Wo liegt das Problem? Was ist die Ursache? Was sind die Optionen? Und was kostet jede Option?

Gezielte Optimierung

Auf Basis der Diagnose setze ich die priorisierten Maßnahmen um:

Vorher-Nachher-Messung

Ich messe die Ladezeiten der betroffenen Seiten und Prozesse vor und nach der Optimierung — damit du konkrete Zahlen hast, nicht nur ein subjektives Gefühl.

Für wen ist das relevant?

Du profitierst von einer Performance-Optimierung, wenn:

Praxisbeispiel

Ein Großhändler mit 45 BC-Nutzern bemerkt, dass die Fakturierung am Monatsende plötzlich zwei- bis dreimal so lange dauert wie noch ein Jahr zuvor. Der Partner empfiehlt ein Upgrade auf eine größere Azure-Instanz.

Die Performance-Diagnose ergibt ein anderes Bild: Eine Custom-Extension für die Preisberechnung führt bei jedem Buchungsvorgang eine Schleife durch alle Preisgruppen durch — statt einen vorberechneten Wert zu cachen. Bei 200 Buchungen am Monatsende summieren sich die unnötigen Datenbankabfragen auf über 40.000 Einzelzugriffe.

Gleichzeitig sind die Belegposten-Tabellen seit fünf Jahren Betrieb ohne Archivierung auf über drei Millionen Einträge angewachsen.

Nach dem Refactoring der Extension und der Einrichtung eines Archivierungslaufs für Daten älter als zwei Jahre: Die Buchungsdauer am Monatsabschluss sank um 68 Prozent. Kein Infrastruktur-Upgrade nötig.

Häufige Fragen

Wie lange dauert eine Performance-Diagnose?

Ein bis zwei Tage für ein mittelgroßes System — abhängig davon wie viele Custom-Extensions vorhanden sind und wie gut die Slow-Query-Logs zugänglich sind. Am Ende hast du eine priorisierte Liste von Ursachen und Maßnahmen. Die Optimierung selbst dauert je nach Umfang ein bis fünf Tage.

Verliere ich Daten wenn historische Einträge archiviert werden?

Nein. BC-Archivierung verschiebt Daten in Archivtabellen oder separate Archive — sie sind weiterhin abrufbar, belasten aber nicht mehr die aktiven Abfragen. Ich richte die Archivierung so ein, dass keine Compliance-relevanten Daten verloren gehen.

Muss ich die Extension neu schreiben lassen oder reicht ein Refactoring?

In den meisten Fällen reicht gezieltes Refactoring der problematischen Stellen. Ein vollständiger Neuschrieb ist nur nötig, wenn die Architektur der Extension grundlegend falsch ist. Ich sage dir das ehrlich in der Diagnose.

Kann eine Performance-Optimierung bei BC SaaS überhaupt etwas bewirken — ich habe doch keinen Zugriff auf den SQL-Server?

Ja. Der Zugriff auf den SQL-Server wäre hilfreich für tiefe Analysen, ist aber nicht notwendig. AL-Code-Optimierung, Job-Queue-Anpassungen, Archivierung und Index-Konfiguration über Custom-Keys wirken direkt auf die Performance — und sind alles, was BC SaaS-Kunden auch ohne SQL-Zugriff steuern können.

Wie läuft das Erstgespräch ab?

30 Minuten. Du schilderst mir das Problem, ich sage dir ob und wie ich helfen kann — direkt, ohne Präsentation. Danach bekommst du eine schriftliche Einschätzung mit Aufwand und Vorgehen. Erst dann entscheidest du ob wir starten.


Projektziel und Aufwand besprechen — ich nenne euch eine ehrliche Einschätzung.

Jetzt anfragen

Kein Jahresvertrag. Kein Mindestvolumen. Du zahlst für das gelöste Problem.

Weitere Themen: AL Code Review Business Central · Business Central Extension Update Fehler · Business Central Schnittstellen

Verwandte Seiten

Über mich

Filip JacobiBusiness Central Solution Architect

Freiberuflicher BC-Entwickler und Consultant aus Bochum. Ich arbeite direkt mit eurem Fachbereich — ohne Agentur-Overhead, ohne Account-Staffelung. Remote und vor Ort in NRW verfügbar.

Mehr über mich und meine Leistungen