Von Alexander LuftJTL Service Partner Gold · Ahrensfelde bei Berlin · 2. Oktober 2025 · 7 Min. Lesezeit
Warum wird JTL-Wawi langsam?
JTL-Wawi ist kein schlankes Desktop-Programm. Dahinter steckt ein vollständiger SQL Server, der Bestellungen, Artikel, Lagerbestände und Workflows in Echtzeit verarbeitet. Wenn die Wawi langsam wird, liegt das fast immer an einer Stelle im System. Und meistens nicht dort, wo man zuerst sucht.
Dieser Artikel zeigt, welche Ursachen tatsächlich hinter Performance-Problemen stecken, wie Hardware und SQL-Konfiguration zusammenspielen und wann eine einfache Server-Entscheidung das größte Ergebnis bringt.
Warum wird JTL-Wawi langsam?
Die häufigsten Ursachen, die ich in Projekten sehe, lassen sich in drei Kategorien einteilen.
Erstens: Hardware, die nicht mehr zur Datenmenge passt. Was bei 5.000 Artikeln und einem Nutzer funktioniert, bricht bei 80.000 Artikeln und zehn gleichzeitigen Arbeitsplätzen zusammen. Die Datenbank wächst, aber die Hardware bleibt dieselbe.
Zweitens: Ein falsch konfigurierter SQL Server. Auto Close und Auto Shrink sind in vielen Express-Installationen noch aktiv. Auto Shrink fragmentiert die Festplatte dauerhaft, weil der Server die Datenbank ständig verkleinert und wieder vergrößert. Das kostet Leistung, die nirgendwo ankommt.
Drittens: Fragmentierte Indexe. JTL baut intern auf einer Vielzahl von Tabellen auf. Wenn Indexe nicht regelmäßig gewartet werden, verlangsamen sich Abfragen spürbar, besonders bei großen Auftragsmengen.
Systemanforderungen: Was JTL tatsächlich voraussetzt
Laut JTL-Guide sind die Mindestanforderungen für den Datenbankserver:
- Betriebssystem: Windows Server 2016 oder höher (Windows Server 2025 wird aktuell nicht unterstützt)
- SQL Server: SQL Server 2022 wird empfohlen, alle Versionen ab 2016 werden unterstützt
- RAM: Mindestens 512 MB für SQL Server Express, 4 GB wenn Reporting Services aktiv sind
- Speicher: Mindestens 6 GB für die Installation plus ausreichend Platz für die Datenbank
- CPU: x64-Prozessor mit mindestens 1,4 GHz
Das sind die technischen Mindestanforderungen. Für einen produktiven Betrieb mit mehreren Arbeitsplätzen sind das keine realistischen Zielwerte. In der Praxis setzen Händler mit 5+ Nutzern und aktiver Marktplatz-Anbindung auf mindestens 8 GB RAM, eine schnelle SSD und mehrere CPU-Kerne.
Für die Clients gilt: Windows 11, .NET Framework mindestens 4.8, Bildschirmauflösung ab 1280 x 1024 Pixel.
SQL Server richtig konfigurieren
Der größte Hebel liegt fast immer auf der SQL-Server-Seite. Laut JTL-Dokumentation sind folgende Einstellungen für die Performance entscheidend:
Auto Close und Auto Shrink deaktivieren. Beide Optionen sind standardmäßig manchmal aktiv und sollten auf „false“ gesetzt werden. Auto Shrink fragmentiert die Datenbank kontinuierlich, Auto Close erzeugt bei jedem Verbindungsaufbau unnötige Verzögerungen.
RAM-Limit korrekt setzen. Für Standard-, Enterprise- und Web-Editionen empfiehlt JTL, dem SQL Server maximal 80 Prozent des verfügbaren Arbeitsspeichers zuzuweisen. Laufen weitere Anwendungen auf demselben Server, sollte dieser Wert auf 60 bis 70 Prozent reduziert werden. Für die Express-Edition gilt: Limit auf 1 GB setzen, damit der Server nicht in die Auslagerungsdatei schreibt.
Kompatibilitätsgrad auf die installierte Version setzen. SQL Server 2022 entspricht Grad 160, SQL Server 2019 ist 150, SQL Server 2017 ist 140, SQL Server 2016 ist 130. Ein veralteter Kompatibilitätsgrad verhindert, dass der Query-Optimizer moderne Ausführungspläne nutzt.
Maximale Parallelität einstellen. Bei bis zu 4 CPU-Kernen empfiehlt JTL einen Wert von 2. Bei mehr als 4 Kernen gilt: Hälfte der CPU-Anzahl minus 1. Bei 8 Kernen also maximal 3 parallele Prozesse.
Datei-Layout: Vier Laufwerke für optimale Performance
Wer ernsthaft in Performance investiert, trennt die SQL-Dateien auf unterschiedliche physische Datenträger. JTL empfiehlt im Guide folgende Aufteilung:
- Laufwerk 1: Betriebssystem und SQL-Server-Installation
- Laufwerk 2: .mdf-Datei (Hauptdatenbankdatei)
- Laufwerk 3: .ldf-Datei (Transaktionslog)
- Laufwerk 4: tempdb-Dateien, auf dem schnellsten verfügbaren Datenträger
Wenn NVMe-SSDs verbaut sind, ist die strikte Trennung weniger kritisch. Die Geschwindigkeit gleicht die fehlende Aufteilung teilweise aus. Für alle anderen Setups macht die Trennung einen messbaren Unterschied.
Für die Dateigrößen empfiehlt JTL einen Startwert von 10 GB für die .mdf-Datei mit einer Auto-Wachstums-Einheit von 500 MB. Für die .ldf-Datei: 3 GB Startgröße, 100 MB Wachstumseinheit. Kleine Auto-Wachstums-Werte bedeuten häufige Speicher-Erweiterungen unter Last. Das bremst.
Indexe und Wartung: Was regelmäßig laufen muss
JTL-Wawi fragmentiert Indexe schneller als viele andere Systeme, weil laufend Artikel, Aufträge und Lagerbestände geschrieben werden. Ohne regelmäßige Wartung verschlechtern sich Abfragezeiten über Wochen deutlich.
In JTL-Wawi ist der Wartungspfad unter Start > Datenbank > Performanceoptimierung zu finden. Laut JTL-Wartungsempfehlung gilt:
- Indexe neu organisieren und neu erstellen: täglich, idealerweise nachts außerhalb der Stoßzeiten
- Statistiken aktualisieren: wöchentlich, abends oder am Wochenende
- Datenbank-Backup: mindestens täglich, Speicherort außerhalb des Servers
Der JTL-Guide weist explizit darauf hin, externe Optimierungstools zu vermeiden, da diese Zugriffsprobleme verursachen können.
Für Nutzer der Standard-, Enterprise- oder Web-Edition besteht die Möglichkeit, automatisierte Maintenance Plans über SQL Server Agent einzurichten. Das wird besonders dann genutzt, wenn die Wawi über Nacht läuft und der Wartungsprozess nicht manuell angestoßen werden soll.
Cloud vs. lokaler Server: Was bringt mehr?
Die Frage kommt regelmäßig auf. Die Antwort hängt davon ab, was gerade das schwächste Glied in der Kette ist.
Ein lokaler Server mit alter Hardware, einer rotierenden Festplatte und einer Express-Edition ist fast immer der Engpass, egal wie gut die Internetanbindung ist. Wer hier auf Cloud wechselt, gewinnt vor allem durch modernere Hardware und schnellen Speicher.
Ein gut konfigurierter lokaler Server mit NVMe-SSD, ausreichend RAM und einer Standard-Edition kann eine Cloud-Lösung in Sachen Latenz schlagen, weil der Netzwerkweg zwischen Client und Datenbankserver kürzer ist. Im lokalen Netzwerk liegt die Latenz im einstelligen Millisekundenbereich. Bei Cloud-Verbindungen hängt alles von der Internetleitung ab.
Zu den Vor- und Nachteilen eines dedizierten JTL-Wawi-Cloud-Servers haben wir eine eigene Seite zusammengestellt: JTL-Wawi Cloud Server
Wann lohnt sich ein dedizierter Server?
Drei Anzeichen, bei denen ein dedizierter Server die richtige Antwort ist:
Erstens: Mehr als drei gleichzeitige Nutzer in der Wawi. Die Express-Edition ist nicht für Mehrbenutzer-Betrieb ausgelegt. Sie hat kein SQL-Agent-Feature und ist auf 10 GB Datenbankgröße begrenzt.
Zweitens: Datenbankgröße nähert sich der 10-GB-Grenze der Express-Edition. Wenn die Datenbank wächst und die Grenze absehbar ist, ist ein Wechsel auf Standard keine Option, sondern Pflicht.
Drittens: Marktplatz-Anbindungen laufen parallel. eazyAuction, Amazon und eBay erzeugen kontinuierlich Datenbankschreibvorgänge. In Kombination mit aktiver Nutzung am Arbeitsplatz entstehen Lastspitzen, die eine Express-Edition überfordern.
Mehr zur Einrichtung und was bei der JTL-Wawi-Konfiguration zu beachten ist, steht auf der Leistungsseite: JTL-Wawi Einrichtung
