Sie öffnen die Rechnungsliste und müssen zehn Sekunden warten. Sie erstellen einen Bericht, und der Browser zeigt einen weißen Bildschirm an, bevor die Daten endlich geladen werden. Sie starten eine Produktsuche, und alles bleibt stehen, während die Datenbank Abfragen abarbeitet. Wenn Ihnen diese Situationen bekannt vorkommen, leidet Ihre Dolibarr-Instanz unter einem Performance-Problem. Und in mehr als achtzig Prozent der Fälle ist der Schuldige weder PHP noch der Browser, sondern die MySQL- oder MariaDB-Datenbank, die hinter Ihrem ERP/CRM steht.

Eine schlecht konfigurierte Datenbank verwandelt ein reaktives Dolibarr in ein Werkzeug, das Ihre Teams am Ende umgehen. Sie greifen wieder zu Excel, zu handgeschriebenen Notizen oder zu Drittanbieter-Tools, und das Versprechen eines einheitlichen Informationssystems bricht zusammen. Die gute Nachricht ist, dass die überwiegende Mehrheit der Langsamkeitsprobleme aus bekannten Ursachen stammt, die identifiziert und behoben werden können. In dieser Anleitung teilt NEXT GESTION fünf technische Tipps, die in Hunderten von Dolibarr-Produktionsinstanzen erprobt wurden, von Händlern mit zehn Benutzern bis hin zu Industrieunternehmen mit mehreren hundert gleichzeitigen Verbindungen. Diese Tipps decken Engine-Konfiguration, Indizes, Wartung, Caches und Server-Architektur ab. Richtig angewandt können sie die Antwortzeiten Ihrer Anwendung durch drei, fünf oder sogar zehn teilen.

Inhaltsverzeichnis

1. Warum Dolibarr mit der Zeit langsamer wird: Die Ursachen verstehen
2. Vorabdiagnose: Messen vor dem Optimieren
3. Tipp Nr. 1: MySQL/MariaDB-Konfiguration optimieren
4. Tipp Nr. 2: An Indizes und Tabellenstruktur arbeiten
5. Tipp Nr. 3: Regelmäßige Datenbankwartung
6. Tipp Nr. 4: Anwendungs-Caches aktivieren und konfigurieren
7. Tipp Nr. 5: Server-Architektur an die Last anpassen
8. Dolibarr-spezifische Optimierungen
9. Kontinuierliche Überwachung und Monitoring
10. Klassische Fehler, die zu vermeiden sind
11. Konkrete Fallstudien
12. Wann sollten Sie einen Experten hinzuziehen?
13. FAQ: Häufige Fragen zur Dolibarr-Performance

1. Warum Dolibarr mit der Zeit langsamer wird: Die Ursachen verstehen

Wenn Sie mit Dolibarr beginnen, ist die Anwendung schnell. Alles läuft reibungslos, Seiten werden sofort angezeigt, und die Benutzererfahrung ist angenehm. Sechs Monate, ein Jahr oder zwei Jahre später benötigt dieselbe Anwendung fünf, zehn oder zwanzig Sekunden, um dieselbe Liste anzuzeigen. Was ist passiert?

Mehrere Phänomene addieren sich. Zunächst nimmt das Datenvolumen zu: Rechnungen, Angebote, Bestellungen, Lagerbewegungen, Buchungen, archivierte E-Mails, angehängte Dateien. Eine Tabelle, die zehntausend Zeilen enthielt, hat jetzt fünfhunderttausend, und einige schlecht geschriebene Abfragen gehen von einer Millisekunde auf zwei Sekunden. Dann steigt die Anzahl gleichzeitiger Benutzer mit dem Wachstum des Unternehmens, was die gleichzeitigen Verbindungen und Sperren auf Tabellen vervielfacht. Im Laufe der Zeit installierte Zusatzmodule bringen ihre eigenen Abfragen und Tabellen mit. Die anfänglich vorhandenen Indizes reichen für neue Anwendungsfälle nicht mehr aus. Der Anwendungs-Cache ist nicht aktiviert oder schlecht dimensioniert. Schließlich wurde die mit Ihrem Hosting gelieferte MySQL-Standardkonfiguration, ausgelegt für einen Server mit einem Gigabyte Speicher, nie an Ihre tatsächliche Infrastruktur angepasst.

Diese Mechanismen zu verstehen ist wesentlich, bevor man handelt. Performance ist kein statischer Zustand, sondern ein dynamisches Gleichgewicht zwischen Datenvolumen, Benutzerlast, Codequalität, verfügbaren Indizes und zugewiesenen Hardware-Ressourcen. Eine effektive Optimierung wirkt gleichzeitig auf mehrere dieser Achsen, und genau das werden wir in den folgenden fünf Tipps detaillieren.

2. Vorabdiagnose: Messen vor dem Optimieren

Die goldene Regel jeder Optimierung lautet einfach: Was man nicht misst, kann man nicht optimieren. Bevor Sie auch nur eine Konfigurationszeile ändern, nehmen Sie sich die Zeit, eine quantifizierte und reproduzierbare Diagnose Ihrer aktuellen Situation zu erstellen. Ohne Baseline werden Sie nicht beurteilen können, ob Ihre Änderungen einen echten Gewinn gebracht haben oder ob Sie das Problem lediglich verlagert haben.

Beginnen Sie damit, die langsamsten Seiten aus Sicht des Benutzers zu identifizieren. Die in Ihren Browser integrierten Entwicklertools, zugänglich über die Taste F12, zeigen die vollständige Ladezeit jeder Seite, die auf dem Server verbrachte Zeit und die Rendering-Zeit auf der Client-Seite an. Notieren Sie diese Messungen für fünf bis zehn kritische Aktionen Ihres Alltags: Öffnen der Rechnungsliste, Kundensuche, Erstellen eines Berichts, Bestätigen einer Bestellung, Zugriff auf eine Produktdatei mit ihren Beständen. Diese Zahlen bilden Ihren Referenzpunkt.

Aktivieren Sie dann das Slow-Query-Log auf MySQL- oder MariaDB-Seite und legen Sie eine niedrige Schwelle fest, beispielsweise eine Sekunde. Dieses Log erfasst alle Abfragen, die diese Verzögerung überschreiten, und enthüllt sofort die Engpässe. In Verbindung mit einem Analysewerkzeug wie pt-query-digest oder mysqldumpslow ordnet es Abfragen nach kumulativer Zeit, Häufigkeit und durchschnittlicher Zeit und zeigt Ihnen genau, worauf Sie Ihre Bemühungen konzentrieren sollten. Untersuchen Sie auch die globalen Server-Statistiken: InnoDB-Cache-Trefferquote, Quote abgebrochener Verbindungen, auf Sperren wartende Abfragen, auf die Festplatte geschriebene temporäre Tabellen. Diese Indikatoren leiten die Diagnose unmittelbar.

Auf Dolibarr-Seite aktivieren Sie den Debug-Modus in der Konfiguration und konsultieren das Anwendungs-Log, um Module oder Hooks zu identifizieren, die jeder Seite Zeit hinzufügen. Messen Sie die Größe Ihrer Datenbank, die Größe jeder Haupttabelle und die Anzahl der enthaltenen Zeilen. Eine Log-Tabelle, die mehrere Gigabyte wiegt, oder eine Ereignistabelle mit mehreren Millionen Zeilen ist ein sofortiges Warnsignal. Sobald dieser Überblick erstellt ist, wissen Sie, wo Sie stehen, und können die Optimierungen mit voller Sachkenntnis angehen.

3. Tipp Nr. 1: MySQL/MariaDB-Konfiguration optimieren

Die Standardkonfiguration von MySQL oder MariaDB ist einer der schnellsten und rentabelsten Hebel, um an Performance zu gewinnen. Sie ist absichtlich konservativ, vorgesehen für einen bescheidenen Server ohne Risiko der Speichersättigung. Auf einem Dolibarr-dedizierten Server mit acht, sechzehn oder zweiunddreißig Gigabyte RAM lässt diese Konfiguration buchstäblich neunzig Prozent der Ressourcen ungenutzt.

Der mit Abstand wirkungsvollste Parameter ist die InnoDB-Buffer-Größe. InnoDB ist die Speicher-Engine, die von allen modernen Dolibarr-Tabellen verwendet wird, und ihr Buffer ist der Speicherbereich, in dem MySQL Daten- und Indexseiten zwischenspeichert. Je größer dieser Buffer, desto weniger muss der Server von der Festplatte lesen, und desto schneller werden Abfragen. Die allgemein akzeptierte Regel besteht darin, etwa siebzig bis achtzig Prozent des gesamten RAM des Servers diesem Buffer zuzuweisen, wenn die Maschine der Datenbank gewidmet ist. Auf einem Shared-Server, der auch PHP und den Webserver hostet, sinkt dies auf fünfzig oder sechzig Prozent, wobei darauf zu achten ist, dass dem Rest des Systems genügend Speicher bleibt.

Andere Parameter verdienen eine sorgfältige Anpassung. Die InnoDB-Log-Größe beeinflusst direkt die Schreibleistung: Ein zu kleines Log löst zu häufige Flushes aus und verlangsamt Massen-Insertionen. Die maximale Anzahl an Verbindungen muss die Realität Ihrer Last widerspiegeln, ohne maßlos zu sein, da jede Verbindung Speicher verbraucht. Der Sortierpuffer, der Join-Puffer und der Cache temporärer Tabellen müssen an Ihre komplexesten Abfragen angepasst sein, ohne so überdimensioniert zu sein, dass sie den RAM bei Lastspitzen sättigen. Der InnoDB-Transaktions-Flush-Modus kann je nach Risikotoleranz angepasst werden: Der sicherste Wert garantiert die Dauerhaftigkeit jeder Transaktion auf Kosten häufigerer Festplattenschreibvorgänge, während ein Zwischenwert einen ausgezeichneten Kompromiss für die meisten KMU bietet.

Schließlich vergessen Sie nicht die Query-Cache-Engine, die jetzt auf neueren MariaDB-Versionen standardmäßig deaktiviert und auf MySQL gänzlich entfernt ist. Wenn Sie noch auf einer alten Version mit aktiviertem Cache sind und Ihre Last hauptsächlich Schreiblast ist, kann er die Anwendung paradoxerweise verlangsamen. Ein Konfigurationsaudit ermöglicht es, präzise zu bestimmen, was aktiviert, angepasst oder deaktiviert werden muss. NEXT GESTION praktiziert diese Übung systematisch bei seinen Einsätzen und liefert auf jede Instanzgröße abgestimmte Konfigurationsdateien.

4. Tipp Nr. 2: An Indizes und Tabellenstruktur arbeiten

Wenn die Engine-Konfiguration der schnellste Hebel ist, sind Indizes der mächtigste. Ein gut platzierter Index kann eine Fünf-Sekunden-Abfrage in eine Eine-Millisekunde-Abfrage verwandeln. Umgekehrt zwingt ein fehlender Index auf einer häufig gefilterten Spalte die Datenbank, die gesamte Tabelle zu durchlaufen, eine Operation, deren Kosten mit dem Datenwachstum explodieren.

Dolibarr wird mit einem vernünftigen Satz von Indizes ausgeliefert, der Standardanwendungen abdeckt. Sobald Sie jedoch Drittanbieter-Module, benutzerdefinierte Felder oder maßgeschneiderte Erweiterungen hinzufügen, können diese Indizes unzureichend werden. Eine Suche nach interner Referenz auf der Produkttabelle, ein Statusfilter auf der Rechnungstabelle kombiniert mit einer Sortierung nach Datum, ein Join zwischen zwei untergeordneten Tabellen eines zusätzlichen Moduls: ebenso viele Szenarien, in denen ein ergänzender Index den Unterschied zwischen einer flüssigen und einer mühsamen Erfahrung ausmacht.

Die Identifizierung fehlender Indizes erfolgt über das Slow-Query-Log und das in MySQL integrierte EXPLAIN-Tool. EXPLAIN beschreibt detailliert die von der Engine für jede Abfrage gewählte Ausführungsstrategie: Verwendung eines Index, vollständiger sequenzieller Lesevorgang, verschachtelter Join, temporäre Tabelle im Speicher oder auf der Festplatte. Eine Abfrage, die das Wort ALL in der type-Spalte zeigt oder mehrere Millionen gescannter Zeilen, ist ein offensichtlicher Kandidat zur Optimierung. Die Erstellung eines gezielten Index, manchmal eines zusammengesetzten über mehrere Spalten in der richtigen Reihenfolge, reicht dann aus, um das Problem zu beheben.

Vorsicht jedoch, nicht ins Übermaß zu verfallen. Jeder Index hat Kosten beim Schreiben: Bei jedem Insert, Update oder Delete muss MySQL die betroffenen Indizes aktualisieren. Das Hinzufügen von zehn Indizes zu einer stark schreibbelasteten Tabelle kann die Gesamtleistung verschlechtern. Die bewährte Praxis besteht darin, das zu indizieren, was tatsächlich genutzt wird, redundante oder ungenutzte Indizes zu entfernen und durchdachte zusammengesetzte Indizes einer Vermehrung einfacher Indizes vorzuziehen. Auf der Strukturseite überprüfen Sie auch, dass Ihre Spalten die richtigen Typen verwenden: Ein großzügig dimensioniertes VARCHAR verbraucht mehr Sortierspeicher als ein angepasstes VARCHAR, ein TEXT, wo ein VARCHAR ausreichen würde, verhindert bestimmte Optimierungen, ein DATE-Typ ist immer schneller als ein als String gespeichertes Datum. Ein Schema-Audit durch einen Dolibarr-Experten identifiziert diese oft vom Interface aus unsichtbaren Verbesserungspunkte.

5. Tipp Nr. 3: Regelmäßige Datenbankwartung

Eine Datenbank ist ein lebender Organismus. Aufeinanderfolgende Inserts, Updates und Deletes fragmentieren Seiten, lassen Indizes über ihre optimale Größe hinaus anschwellen, desynchronisieren die vom Query-Optimierer verwendeten Statistiken und sammeln veraltete Daten an, die niemand mehr konsultiert. Ohne regelmäßige Wartung verschlechtern diese Phänomene schließlich spürbar die Leistung, selbst ohne neue Geschäftsaktivität.

Die erste Wartungsoperation ist die Defragmentierung der Tabellen. Auf InnoDB wird diese Operation durch einen Befehl durchgeführt, der die Tabelle und ihre Indizes neu aufbaut, indem freier Speicherplatz zurückgewonnen, Seiten neu organisiert und die Größe der Datendatei angepasst wird. Quartalsweise auf den Haupttabellen durchgeführt, begrenzt sie die künstliche Datenbankexpansion und bewahrt die Datenlokalität, also die physische Nähe häufig gemeinsam gelesener Zeilen. Stark schreibbelastete Tabellen wie die Buchungstabelle, die Journaltabelle oder die Stocktabelle profitieren besonders von dieser Defragmentierung.

Die zweite Operation ist die Aktualisierung der Statistiken. Der MySQL-Optimierer wählt seinen Ausführungsplan basierend auf Statistiken, die die Index-Kardinalität und die Wertverteilung schätzen. Wenn diese Statistiken veraltet sind, kann der Optimierer absurde Entscheidungen treffen, beispielsweise sich weigern, einen perfekt geeigneten Index zu verwenden, weil er denkt, die Tabelle enthalte noch tausend Zeilen, während sie jetzt eine Million enthält. Der Statistik-Update-Befehl, der periodisch ausgeführt wird, gewährleistet, dass die Ausführungspläne relevant bleiben.

Die dritte Operation ist die Archivierung und Bereinigung veralteter Daten. Anwendungs-Logs, abgelaufene Sitzungen, E-Mail-Anhänge von vor fünf Jahren, nicht validierte Zwischendokumente, on-the-fly generierte Berichte: ebenso viele Daten, die Platz beanspruchen ohne realen Geschäftswert. Eine klare, dokumentierte und automatisierte Aufbewahrungsrichtlinie ermöglicht es, das Volumen unter Kontrolle zu halten. Auf einigen Datenbanken, die NEXT GESTION auditiert hat, waren mehr als sechzig Prozent des Volumens Daten gewidmet, die kein Benutzer seit Jahren konsultiert hatte. Eine einfache Bereinigung mit Offline-Archivierung ermöglichte es, die Datenbankgröße durch drei zu teilen und mechanisch alle Operationen zu beschleunigen.

Vergessen Sie schließlich nicht die Integritätsprüfung. Eine stille Korruption, selbst eine geringfügige, auf einer kritischen Tabelle kann aberrante Verhaltensweisen erzeugen, die schwer zu diagnostizieren sind. Eine monatliche Überprüfung der Haupttabellen und eine Verfolgung der MySQL-Fehlerlogs verhindern Vorfälle, bevor sie auf der Benutzerseite sichtbar werden.

6. Tipp Nr. 4: Anwendungs-Caches aktivieren und konfigurieren

Die beste Abfrage ist die, die man nicht ausführt. Diese Maxime fasst die Cache-Logik perfekt zusammen: Das Ergebnis kostspieliger Operationen im Speicher behalten, um sie bei nachfolgenden Abfragen sofort bereitzustellen. Dolibarr und sein PHP-Ökosystem bieten mehrere Cache-Ebenen, die richtig konfiguriert die Datenbanklast drastisch reduzieren können.

Der erste zu aktivierende Cache ist der PHP-OPcache. Ohne OPcache liest, parst und kompiliert PHP jede Quelldatei bei jeder Anfrage neu, was CPU und Zeit erheblich verbraucht. Mit aktiviertem OPcache wird der kompilierte Bytecode im Speicher behalten und wiederverwendet, was die globale Antwortzeit der Anwendung halbieren kann. Die Konfiguration besteht darin, ausreichend Speicher zuzuweisen, um alle Dateien von Dolibarr zu speichern, eine mit der Größe Ihrer Installation kohärente Anzahl von Dateien zu autorisieren und die Validierungsparameter anzupassen, um unnötige Überprüfungen in der Produktion zu vermeiden. Es ist eine einfache, kostenlose Optimierung mit fast systematisch spektakulärem Gewinn.

Die zweite Ebene betrifft den Anwendungscache von Dolibarr selbst. Mehrere Bereiche der Anwendung können gecacht werden: Listen von Ländern, Währungen, Zahlungsarten, Benutzerrechten, globalen Konfigurationsparametern, Übersetzungen. Diese Daten werden auf fast jeder Seite gelesen, ändern sich aber sehr selten. Sie im Speicher zu behalten vermeidet Dutzende oder sogar Hunderte redundanter Abfragen bei jedem Laden. Je nach installierten Modulen und verwendeter Version können diese Caches über erweiterte Parameter oder dedizierte Erweiterungen aktiviert werden.

Für Instanzen mit höherer Last ist es relevant, mit einem externen Cache, der zwischen PHP-Prozessen geteilt wird, weiter zu gehen. Lösungen wie Redis oder Memcached ermöglichen es, Ergebnisse komplexer Abfragen, Benutzersitzungen oder rekonstituierte Geschäftsobjekte zu cachen. Der Gewinn ist besonders deutlich auf Dashboards, Zahlenaggregationen und gleichzeitig von vielen Benutzern geladenen Seiten. Die Implementierung erfordert eine sorgfältige Konfiguration, eine rigorose Invalidierungsstrategie und eine aktive Überwachung, um die Konsistenz der angezeigten Daten zu gewährleisten. Dies ist typischerweise ein Einsatz, den NEXT GESTION durchgängig auf den anspruchsvollsten Dolibarr-Instanzen begleitet.

Vergessen wir nicht den Browser-Cache und den HTTP-Cache. Statische Ressourcen von Dolibarr wie Stylesheets, JavaScript-Skripte und Bilder müssen mit angemessenen Cache-Headern bereitgestellt werden, um zu vermeiden, dass sie bei jeder Seite erneut heruntergeladen werden. Eine sorgfältige Webserver-Konfiguration, gegebenenfalls ergänzt durch ein CDN für Multi-Site-Deployments, entlastet die Netzwerklast und verbessert die wahrgenommene Geschwindigkeit auf Benutzerseite.

7. Tipp Nr. 5: Server-Architektur an die Last anpassen

Alle Software-Optimierungen der Welt können einen unterdimensionierten Server oder eine ungeeignete Architektur nicht ausgleichen. Ab einem bestimmten Datenvolumen, gleichzeitigen Benutzern oder verbundenen Integrationen wird es notwendig, die Hardware-Grundlage, auf der Ihr Dolibarr ruht, zu überprüfen.

Der erste zu untersuchende Parameter ist der verfügbare Arbeitsspeicher. Eine performante Datenbank benötigt RAM in Hülle und Fülle, hauptsächlich für den oben erwähnten InnoDB-Buffer. Die empirische Regel besteht darin, einen Gesamt-RAM mindestens gleich der Größe des aktiven Teils Ihrer Datenbank anzustreben, also der Tabellen und Indizes, die Sie regelmäßig konsultieren. Ein Acht-Gigabyte-Server für eine fünfzehn Gigabyte aktive Datenbank wird die Hälfte seiner Zeit damit verbringen, von der Festplatte zu lesen, unabhängig von Ihrem Tuning. Den RAM zu erhöhen ist oft die rentabelste Hardware-Investition.

Der zweite Parameter ist das Speicher-Subsystem. Der Wechsel von einer mechanischen Festplatte zu einer SSD teilt im Allgemeinen die Latenzen für zufälliges Lesen durch zehn, was die Benutzererfahrung bei komplexen Abfragen transformiert. Der Wechsel von einer SATA-SSD zu einer NVMe-SSD bringt einen erheblichen zusätzlichen Gewinn bei schreibintensiven Lasten. Bei virtualisiertem Hosting überprüfen Sie die angebotene Speicherklasse und zögern Sie nicht, eine höhere Klasse zu wählen, wenn Ihre Messungen auf einen Festplatten-Engpass hinweisen.

Der dritte Parameter betrifft die CPU. Dolibarr und seine PHP-Engine sind bei einzelnen Abfragen empfindlich gegenüber der Taktfrequenz, noch mehr als gegenüber der Anzahl der Kerne. Bei Multi-User-Lasten wird hingegen die Anzahl der Kerne bestimmend, um parallele Anfragen zu absorbieren. Ein Audit der durchschnittlichen Last, der Spitzen und der Art der Operationen ermöglicht es, die richtige Kombination zu wählen.

Über die vertikale Dimensionierung einer einzelnen Maschine hinaus existieren fortgeschrittenere Architekturen für stark beanspruchte Instanzen. Die Trennung von Webserver und Datenbankserver auf zwei verschiedenen Maschinen verteilt die Last und vermeidet Ressourcenkonflikte. Die Einrichtung einer Primär-Sekundär-Replikation ermöglicht es, schwere Leseabfragen auf eine Replik zu entladen, während Schreibvorgänge auf dem Hauptserver verbleiben. Die Verwendung eines Connection-Proxys zur Bündelung der PHP-Verbindungen auf der MySQL-Seite reduziert die Spitzenlast. Diese Architekturen rechtfertigen sich ab einer bestimmten Kritikalitäts- oder Volumenschwelle und fügen sich in eine globale Reflexion über Hochverfügbarkeit ein, die NEXT GESTION mit seinen Mid-Cap- und Großkundenkunden durchführt.

Schließlich spielt das Netzwerk eine oft unterschätzte Rolle. Eine übermäßige Latenz zwischen dem Browser des Benutzers, dem Webserver und dem Datenbankserver verschlechtert die Erfahrung erheblich, insbesondere auf Seiten mit vielen Hin- und Hertransfers. Ein Hosting in geografischer Nähe Ihrer Hauptbenutzer und ein internes Netzwerk mit niedriger Latenz zwischen den verschiedenen Bausteinen der Architektur machen oft den Unterschied bei intensiven Geschäftsworkflows.

8. Dolibarr-spezifische Optimierungen

Über die Datenbank-Engine und die Architektur hinaus bietet Dolibarr selbst mehrere Optimierungshebel. Die Deaktivierung ungenutzter Module ist wahrscheinlich der einfachste und effektivste. Jedes aktivierte Modul lädt seine eigenen Bibliotheken, führt seine Hooks auf jeder Seite aus und verbraucht Ressourcen, auch wenn Sie es nicht verwenden. Die Sortierung der wirklich notwendigen Module reduziert die Anzahl der Abfragen pro Seite und beschleunigt das globale Laden.

Die Verwaltung benutzerdefinierter Felder verdient ebenfalls besondere Aufmerksamkeit. Ein schlecht gestaltetes benutzerdefiniertes Feld, beispielsweise eine Dropdown-Liste, die durch eine schwere Abfrage ohne Cache gespeist wird, kann jede Datei-Öffnung erheblich verlangsamen. Bevorzugen Sie zielgerichtete Felder, statische Listen, wenn möglich, und optimierte Abfragen mit angemessenen Indizes.

Massenexporte und schwere Berichte müssen in Bezug auf Systemauswirkungen bedacht werden. Ein Export von hunderttausend Zeilen, der mitten am Tag von einem Benutzer gestartet wird, kann die Anwendung für alle anderen lähmen. Die Einrichtung von Warteschlangen, Nachtplanung oder Hintergrundgenerierung ermöglicht es, diese Operationen zu isolieren, ohne die interaktive Erfahrung zu beeinträchtigen.

Auf der Interface-Seite zeigen einige Listen standardmäßig teure aggregierte Informationen wie die Summe der offenen Rechnungen oder den bewerteten Bestand eines Produkts an. Wenn diese Informationen für die tägliche Nutzung nicht kritisch sind, entlastet ihre Deaktivierung oder Berechnung auf Anfrage das Rendering jeder Zeile und beschleunigt die Navigation. NEXT GESTION begleitet seine Kunden bei der Feinanpassung dieser Anzeigen, um die Performance an die echten Geschäftsbedürfnisse anzupassen.

9. Kontinuierliche Überwachung und Monitoring

Einmal optimieren reicht nicht aus. Eine Dolibarr-Instanz entwickelt sich ständig: neue Benutzer, neue Module, neue Daten, neue Anwendungen. Ohne kontinuierliche Überwachung verschlechtern sich hart erkämpfte Gewinne heimtückisch. Permanentes Monitoring einzurichten ist daher ein unverzichtbarer Schritt jedes nachhaltigen Performance-Ansatzes.

Das Monitoring deckt mehrere Achsen ab. Auf Systemebene verfolgt man die CPU-Auslastung, den freien Speicher, die Speicher-Latenz und den Durchsatz, die durchschnittliche Last und die Anzahl aktiver Prozesse. Auf Datenbankebene überwacht man die InnoDB-Buffer-Trefferquote, die Anzahl langsamer Abfragen pro Minute, aktive Verbindungen, wartende Sperren und die Größe der Haupttabellen. Auf Anwendungsebene instrumentiert man die meistgenutzten Seiten, um ihre Antwortzeit zu messen und Regressionen zu erkennen.

Diese Metriken müssen in einem zentralisierten Werkzeug gesammelt werden, das die Visualisierung von Trends im Zeitverlauf, die Definition von Alarmen bei Schwellenüberschreitung und die Korrelation von Ereignissen ermöglicht. Open-Source-Tools wie Prometheus mit Grafana oder All-in-One-Lösungen wie Zabbix oder dedizierte SaaS-Angebote ermöglichen die Einrichtung dieser Vorrichtung ohne unverhältnismäßige Investitionen. Ein klares Dashboard, wöchentlich konsultiert, gibt einen Gesamtüberblick über die Plattformgesundheit und leitet korrigierende Maßnahmen.

Die Vorfallsverfolgung vervollständigt das Bild. Jede vom Benutzer gemeldete Verlangsamung muss protokolliert, datiert, mit den Systemmetriken des Moments in Beziehung gesetzt und analysiert werden. Mit der Zeit entstehen Muster: Montagmorgen sättigt immer, das Monatsende belastet die Buchhaltung, bestimmte Benutzer lösen atypische Operationen aus. Diese feine Kenntnis des tatsächlichen Verhaltens Ihrer Instanz ist wertvoll, um zu antizipieren, anstatt zu erleiden.

10. Klassische Fehler, die zu vermeiden sind

In der Dringlichkeit eines Performance-Problems richten bestimmte gut gemeinte Versuche mehr Schaden als Nutzen an. Der erste Fehler besteht darin, mehrere Parameter gleichzeitig zu ändern, ohne die Auswirkungen jeder Änderung zu messen. Wenn sich die Situation verbessert, werden Sie nicht wissen, welcher gewirkt hat. Wenn sie sich verschlechtert, werden Sie nicht in der Lage sein, präzise zurückzurollen. Jede Änderung muss isoliert, gemessen und validiert werden, bevor zur nächsten übergegangen wird.

Der zweite Fehler ist das Kopieren-Einfügen einer in einem Blog gefundenen MySQL-Konfiguration ohne sie zu verstehen. Eine für einen Webserver mit hohem Verkehr optimierte Konfiguration hat nichts mit einer für ein transaktionales ERP geeigneten zu tun. Eine missverstandene Parameterdatei kann Bugs vervielfachen, den RAM sättigen oder sogar den Dienststart verhindern.

Der dritte Fehler ist Überindexierung. Angesichts langsamer Abfragen ist die Versuchung, einen Index auf jeder in einem WHERE erwähnten Spalte hinzuzufügen. Das ist selten die richtige Antwort. Ein gut durchdachter Index ist mehr wert als zehn redundante, und jeder hinzugefügte Index benachteiligt Schreibvorgänge.

Der vierte Fehler besteht darin, Backups vor einem Eingriff zu ignorieren. Eine Optimierung, insbesondere bei Indizes oder Tabellenstruktur, muss von einem vollständigen, verifizierten und wiederherstellbaren Backup vorangegangen sein. Ohne Sicherheitsnetz auf einer Produktionsdatenbank zu arbeiten, ist ein Risiko, das niemand eingehen sollte.

Schließlich ist der fünfte Fehler die Unterschätzung des Lerneffekts. Eine Optimierung entfaltet ihre volle Wirkung, sobald die Caches warm sind, die Statistiken aktuell sind und die Benutzer ihre Gewohnheiten wiedergefunden haben. Den Einfluss in der ersten Stunde zu messen kann ein irreführendes Bild geben. Lassen Sie es mehrere Tage laufen, bevor Sie endgültige Schlussfolgerungen ziehen.

11. Konkrete Fallstudien

Um diese Prinzipien in der Realität zu verankern, hier drei Beispiele aus den Einsätzen von NEXT GESTION, anonymisiert, aber den angetroffenen Situationen treu.

Erster Fall, ein Händler für Profimaterial, der Dolibarr seit fünf Jahren verwendet, mit einer Datenbank von zwölf Gigabyte und etwa fünfundzwanzig gleichzeitigen Benutzern. Die Diagnose offenbart einen InnoDB-Buffer von hundertachtundzwanzig Megabyte, dem Standardwert, auf einem Server mit sechzehn Gigabyte RAM. Erster Eingriff: Anpassung der MySQL-Konfiguration mit dem Buffer auf zehn Gigabyte erhöht. Sofortiges Ergebnis, Antwortzeiten durch drei geteilt auf allen Bildschirmen. Zweiter Eingriff: Analyse des Slow-Query-Logs und Erstellung von vier ergänzenden Indizes auf stark genutzten benutzerdefinierten Feldern. Ergebnis, die Berichte gehen von zwölf Sekunden auf weniger als zwei. Dritter Eingriff: Bereinigung von acht Jahren Anwendungs-Logs und verwaisten Anhängen. Ergebnis, Datenbank auf fünf Gigabyte reduziert und Backups doppelt so schnell.

Zweiter Fall, ein industrielles KMU, das sein MRP mit Dolibarr und mehreren Zusatzmodulen verwaltet. Die Bedarfsberechnungen dauerten mitten am Tag über vierzig Minuten und blockierten die Anwendung. Die Diagnose identifiziert eine Kombination aus schlecht optimierten Abfragen, Fehlen geeigneter Indizes auf den Stücklistenexplosionstabellen und deaktiviertem OPcache. Nach Überarbeitung der kritischen Abfragen, Hinzufügen von fünf gezielten Indizes und Aktivierung von OPcache fällt die Gesamtberechnung auf vier Minuten und kann gestartet werden, ohne die Benutzer zu stören.

Dritter Fall, ein E-Commerce-Großhändler mit einem Dolibarr, das über einen Konnektor mit einem Online-Shop verbunden ist und permanent Bestände und Bestellungen synchronisiert. Unter Last wurde die Anwendung unbenutzbar. Diagnose: gesättigte Mono-Server-Architektur, Fehlen externen Caches, repetitive Abfragen auf wenig variablen Daten. Einrichtung einer Trennung von Webserver und Datenbankserver, Hinzufügen eines Redis-Caches für die Referenzlisten und Optimierung der Konnektor-Abfragen. Ergebnis, eine stabile Plattform selbst in vollen Verkaufskampagnen, mit Antwortzeiten durch fünf geteilt.

12. Wann sollten Sie einen Experten hinzuziehen?

Viele Optimierungen liegen in Reichweite eines Systemadministrators oder eines erfahrenen Dolibarr-Integrators. Konfigurationsanpassungen, OPcache-Aktivierung, Einrichtung eines Basis-Monitorings, Bereinigung veralteter Daten können intern mit etwas Methode und Vorsicht durchgeführt werden.

Bestimmte Situationen rechtfertigen jedoch den Eingriff eines Experten. Wenn Ihre Messungen nicht zu einer klaren Ursache konvergieren, wenn übliche Optimierungen nicht die erwarteten Gewinne erzielen, wenn Ihre Instanz mehrere komplexe Module kombiniert oder die üblichen Volumetrien überschreitet, macht die akkumulierte Erfahrung eines Spezialisten den Unterschied. Ein tiefgreifendes Audit identifiziert Punkte, die einem ungeübten Auge entgehen können: ein nicht optimales Datenschema, eine PHP-Abfrage, die Hunderte von Unterabfragen erzeugt, ein Drittanbieter-Modul, das unverhältnismäßige Ressourcen verbraucht, eine Systemkonfiguration, die mit der tatsächlichen Last unvereinbar ist.

NEXT GESTION begleitet seine Kunden in allen Phasen dieses Ansatzes. Dokumentiertes Performance-Audit, quantifizierter Optimierungsplan, Implementierung der Korrekturen, Schulung interner Teams im Monitoring und kontinuierlichem Tuning, proaktive Wartungsverträge. Unsere Methode beruht auf Messung, Transparenz und Kompetenztransfer, damit Ihre Teams nach unserem Eingriff autonom bleiben. Wenn Ihr Dolibarr verlangsamt und Sie Klarheit haben wollen, kontaktieren Sie uns für eine Vorabdiagnose.

13. FAQ: Häufige Fragen zur Dolibarr-Performance

Mein Dolibarr ist nur auf bestimmten Seiten langsam, sollte ich trotzdem den ganzen Server optimieren? Nein. Eine gezielte Verlangsamung weist fast immer auf ein spezifisches Problem hin: schlecht geschriebene Abfrage, fehlender Index, bestimmtes Modul, teure Berechnung. Die Analyse des Slow-Query-Logs und die Verwendung von EXPLAIN reichen oft aus, um die Ursache zu identifizieren. Eine globale Server-Optimierung kommt im zweiten Schritt, wenn die Diagnose dies rechtfertigt.

Wie lange dauert ein vollständiges Performance-Audit? Für eine Standard-KMU-Instanz erfordert ein vollständiges Audit einschließlich MySQL-Konfiguration, Indizes, Abfragen, Architektur und Anwendungscode zwischen zwei und fünf Tagen je nach Komplexität. Die Schlussfolgerungen werden in einem detaillierten Bericht mit einem priorisierten Aktionsplan geliefert.

Muss man Dolibarr aktualisieren, um an Performance zu gewinnen? Oft ja. Jede Hauptversion bringt ihren Anteil an Optimierungen bei den kritischsten Abfragen, zusätzlichen Indizes und manchmal einer kompletten Neugestaltung von Modulen. Die Migration von einer alten zu einer neueren Version bringt im Allgemeinen einen messbaren Gewinn, ergänzend zu den anderen Optimierungshebeln.

Kann Shared Hosting Dolibarr korrekt betreiben? Für eine sehr kleine Struktur mit wenigen Benutzern und wenig Daten ja. Darüber hinaus werden die Grenzen von Shared-Hostings bei MySQL-Speicher, PHP-Prozessen und Festplattenlatenz prohibitiv. Ein dedizierter VPS, selbst ein bescheidener, bietet ein viel besseres Preis-Leistungs-Verhältnis, sobald man die Schwelle von einigen hundert Rechnungen pro Monat überschreitet.

Hängen die Performances von der Anzahl der Benutzer oder der Datenbankgröße ab? Beides, aber unterschiedlich. Die Datenbankgröße beeinflusst die Dauer einzelner Abfragen und den Druck auf den InnoDB-Buffer. Die Anzahl gleichzeitiger Benutzer beeinflusst den Sperrwettbewerb, den CPU-Verbrauch und den Speicher der PHP-Prozesse. Eine effektive Optimierung berücksichtigt beide Dimensionen.

Sollte man regelmäßig alte Daten bereinigen? Ja, unter Beachtung der gesetzlichen Aufbewahrungspflichten. Buchhaltungsdokumente, Rechnungen, Erklärungen müssen für die anwendbaren gesetzlichen Fristen aufbewahrt werden. Hingegen können technische Logs, Sitzungen, temporäre Dateien und veraltete Anhänge ohne Risiko archiviert oder bereinigt werden, mit einem nennenswerten Performance-Gewinn.

Würde der Wechsel zu PostgreSQL einen Gewinn bringen? PostgreSQL ist eine ausgezeichnete Datenbank-Engine und Dolibarr kann auf PostgreSQL laufen. Der reine Performance-Gewinn ist nicht systematisch: Gut konfiguriertes MySQL/MariaDB bleibt für Dolibarrs Lastprofil sehr leistungsfähig. Die Wahl gehört eher der Infrastrukturstrategie und den verfügbaren Kompetenzen als einem offensichtlichen Performance-Vorteil.

Meine Backups verlangsamen die gesamte Anwendung, was tun? Ein schlecht gestaltetes Backup sperrt Tabellen und blockiert Benutzer. Bevorzugen Sie Tools, die Hot-Backups ohne Sperren durchführen, planen Sie vollständige Backups außerhalb der Geschäftszeiten, verwenden Sie Replikation, um Backups auf eine Replik zu verlagern. Eine optimierte Backup-Strategie bewahrt sowohl Sicherheit als auch Performance.

Artikel verfasst von NEXT GESTION, Dolibarr-Experte und Begleitung von Unternehmen bei der Optimierung, Sicherung und Weiterentwicklung ihres ERP/CRM. Möchten Sie die Performance Ihrer Dolibarr-Instanz auditieren? Kontaktieren Sie unsere Berater: contact@nextgestion.com.