Neu SQL Server Sizing | Netzwerkinstallation, ~100 User

bbtd

Neues Mitglied
29. August 2022
7
0
Hallo liebe JTL Community,

wir benötigen Hilfe von JTL (Datenbank) Experten die sich mit größeren Umgebungen auskennen: Es geht um das Sizing des SQL Servers für JTL.
Unsere Benutzer klagen immer wieder mal, dass "die Wawi" langsam sei - ich kann aber leider aus der IT-Admin Perspektive nicht feststellen warum oder wieso...

Währen der normalen Bürozeiten arbeiten ~100 User mit dem System gleichzeitig - derzeit noch auf Version 1.5.55.2 (Update auf 1.5.55.4 für nächste Woche, 1.6 für Mitte September geplant)

Der aktuelle Datenbankserver hat folgende Specs:
  • Läuft als virtuelle Maschine (Hyper-V)
  • 8vCPU (Xeon Silver 4215R @ 3.20GHz)
  • 32 GB RAM
  • 10GBit/s Netzwerkanbindung
  • SQL Server Standard 2019 (15.0.4236.7)
  • B:\ Festplatte für SQL Backups
  • C:\ Festplatte nur für Windows
  • D:\ Festplatte für SQL Datenbank
  • L:\ Festplatte für SQL Logs
  • T:\ Festplatte für SQL TempDB
  • Alle Festplatten liegen auf dem lokalen Storage des Hyper-V Servers -> D:\ -> ReFS Formatiert, 64k BlockSize
  • Das Storage wird durch einen Hardware RAID Controller zur Verfügung gestellt: 8x 900GB SSDs als RAID10: 64KB Stripe Size
Die SQL VM, sowie der Hyper-V Server selbst wird komplett via PRTG überwacht - laut PRTG liegt die Auslastung beim SQL VM irgendwo hier: CPU: ~10% "Grundrauschen" → während der Bürozeiten irgendwo zwischen 30-50%, RAM, Traffic, Disk I/O alles im grünen Bereich..
→ Hier erkenne ich kein Bottleneck dass die VM oder der Server selbst irgendwo an Grenzen kommt.

Was wir sonst noch gemacht haben:
  • Diverse SQL Settings ausprobiert: Gerade läuft der Server mit folgenden Settings:
    • Arbeitsspeicher: MIn = 13279MB, Max = 26558mb | Arbeitsspeicher für Indexerstellung = 0 | Mindestmenge an Arbeitsspeicher pro Abfrage = 1025KB
    • Prozessoren: Affinität + E/A Affinität = Auto | Maximale Arbeitsthreadanzahl = 0
    • Erweitert > Parallelität: Kostenschwellenwert für Parallelität = 80 | MaxDOP = 4
  • Die Clients möglichst nah an den SQL Server gebracht - via RDS Farm und für alle Remote-Arbeiter (andere Standorte, Homeoffice, etc.) die JTL Wawi als RemoteApp zur Verfügung gestellt.
    → die RDS Farm liegt auf dem selben Hyper-V Host
  • den Worker auf eine eigene VM verfrachtet, dass dieser für Workflows, Shopabgleich und Co. keine CPU Ressourcen von der SQL VM "klaut"
    → auch hier: die VM für für den Worker liegt auf dem selben Hyper-V Host
Bisher habe ich leider noch keine Best-Practices dafür gefunden, weswegen wir (auch zusammen mit dem JTL Support) etwas nach Trial and Error vorgegangen sind und immer wieder mal die SQL Settings (vor allem die Parallelitäts-Geschichten) justiert haben.

Deshalb meine Frage:
→ Kann hier jemand helfen? Bzw. gibt es vielleicht vergleichbare Installationen oder Menschen mit Erfahrungswerten auf die man einen DB Server für JTL hin tunen muss/kann?

Für Rückfragen stehe ich natürlich gerne zur Verfügung.
 

RECENTmarketing

Offizieller Servicepartner
SPBanner
8. Juli 2015
487
129
Wuppertal
Hey @bbtd,

spannendes Thema.

Was genau wird unter die " Wawi ist langsam" verstanden?

Im Laufe der Jahre haben wir einige etliche Differenzierungen kennen lernen dürfen.

Wir kennen uns aus im Betrieb in größeren Umgebungen, gerne stehen wir für einen Austausch zur Verfügung, meld dich gerne per PN.
 

sebjo82

Gut bekanntes Mitglied
3. Juni 2021
426
98
Spoiler: das wird nicht besser - die Wawi ist immer langsam.
Das liegt daran, dass SQL Server mit 5 Millionen Mini-Queries bombardiert wird jedes Mal wenn man einen Auftrag oder Artikel öffnen will
Du kannst nur einen Nutzer haben auf einer DB mit einem Artikel, einen Supercomputer und trotzdem wirst du kurz eben warten müssen bis sich das neue Fenster öffnet
 

MichaelH

Sehr aktives Mitglied
17. November 2008
13.206
1.243
Einerseits die WAWI selbst, das stimmt sicherlich.

RAID10: 64KB Stripe Size - ist niedrig.
32GB ist arg wenig, mein kleines Ding hat schon 128GB, ob RAM einen Engpass hat müsstest du aber an der Festplatten-Aktivität erkennen können.
HyperV ist immer die Frage, jede Virtualisierung frisst deinen Server auf, natürlich hat HyperV andere Vorteile.
- Ich habe eine nette HyperV-Maschine, aber eine lokale Testinstallation auf einem normalen PC ist schneller mit der Test-WAWI.
- Aber 1 aktiver User ist kein Maßstab, die WAWI ist nicht "schnell", entscheidend ist wann das Ding in die Knie geht.
- HyperV aus Sicherheitsgründen, aber ich würde auf der Hardware nur die WAWI virtualisieren und nichts anderes draufpacken

Und die Erfahrung von JTL selbst mit 100 aktiven WAWI-User am Server dürfte eher gering sein, vielleicht ist JTL selbst interessiert der Sache auf den Grund zu gehen ?
Du bist ja ein gutes Test-Beispiel. ;)
Und kann uns letztlich allen nützen.

Also bleib dran.
 

bbtd

Neues Mitglied
29. August 2022
7
0
64k Blöcke sind notwendig, weil der SQL-Server nur 64k-Blöcke lesen kann. Das ist fest vorgegeben.
Exakt - die Settings kommen auch nicht von ungefähr, sondern sind nach Best Practices konfiguriert - Microsoft selbst hat mittlerweile sehr ausführliche Dokumentationen was hier einzustellen und welche Daten wo abzulegen sind. Beispiel: https://docs.microsoft.com/en-us/az...idelines-best-practices-storage?view=azuresql (Storage Part gilt ja auch für den OnPrem Betrieb)
 

bbtd

Neues Mitglied
29. August 2022
7
0
Spoiler: das wird nicht besser - die Wawi ist immer langsam.
Das liegt daran, dass SQL Server mit 5 Millionen Mini-Queries bombardiert wird jedes Mal wenn man einen Auftrag oder Artikel öffnen will
Das mit der Query Thematik ist mir bewusst - auch hier haben wir versucht alles zu tun was es eben einzustellen gibt:
  1. optimize for ad-hoc workload: https://docs.microsoft.com/de-de/sq...er-configuration-option?view=sql-server-ver15
  2. RDS Server möglichst nah an den SQL Server gepackt (auf den selben Hyper-V Host) und die Mitarbeiter:innen per RemoteApp auf die Wawi zugreifen lassen
 

bbtd

Neues Mitglied
29. August 2022
7
0
Einerseits die WAWI selbst, das stimmt sicherlich.

RAID10: 64KB Stripe Size - ist niedrig.
32GB ist arg wenig, mein kleines Ding hat schon 128GB, ob RAM einen Engpass hat müsstest du aber an der Festplatten-Aktivität erkennen können.
HyperV ist immer die Frage, jede Virtualisierung frisst deinen Server auf, natürlich hat HyperV andere Vorteile.
- Ich habe eine nette HyperV-Maschine, aber eine lokale Testinstallation auf einem normalen PC ist schneller mit der Test-WAWI.
- Aber 1 aktiver User ist kein Maßstab, die WAWI ist nicht "schnell", entscheidend ist wann das Ding in die Knie geht.
- HyperV aus Sicherheitsgründen, aber ich würde auf der Hardware nur die WAWI virtualisieren und nichts anderes draufpacken
Hier hätte ich gerne ein paar detailliertere Infos:
  • 64kb stripe size haben wir ja bereits geklärt.
  • Hyper-V und nur die Wawi draufpacken? Warum das? Wie gesagt: der Host langweilt sich, sowohl RAM als auch CPU technisch...
    • CPU technisch würde mich mal interessieren, welchen Effekt bei den ~100 concurrent connections eine höhere Single Thread Performance (sprich schnellere Kerne) oder eben mehr Cores haben..
  • 32GB RAM für die VM: Hier lasse ich gerne mit mir reden - was wäre denn hier die Empfehlung und wie lässt sich das sizen? (sprich berechnen?)
    • Ein paar Fakten am Rand:
    • Server Settings > Memory: Minimum Server Memory = 13279 MB, Maximum Server Memory = 26558 MB, Index creation memory = 0 (dynamic), Minimum Memory per Query = 1024 KB
    • die eazybusiness DB ist derzeit knapp 47GB groß.
    • Recovery Model = Simple, Target Recovery Time = 60 Sekunden, Kein Transaction Log Shipping
    • Auto Close = False, Auto Create Incremental Statistics = False, Auto Create Statistics = True, Auto Shrink = False, Auto Update Statistics = True, AUto Update Statistics Async = False
    • Query Store: Read write, Data Flush Interval = 15min, Statistics Collection Interval = 1h, Max Plans per Query = 200, Max Size = 1000MB, Query Store Capture Mode = Auto, Size Based Cleanup Mode = Auto, Stale Query Threshold = 30 Days, Wait Statistics Capture Mode = On | --> Derzeit von 1000MB Query Store sind 776MB in use und 224MB frei --> 25% Puffer
 

MichaelH

Sehr aktives Mitglied
17. November 2008
13.206
1.243
Tja, das ist das ewige Rätsel.

Super Server für Shop. super Server für WAWI, die Server langweilen sich, kaum Auslastung, die Antwortzeiten sind aber "mau".
Letztlich war es dann immer etwas mit Einstellungen und Software das hinderlich war.
Es gibt einige Möglichkeiten, Netzwerk limitiert, Zugriff Client / DB limitiert (auf der gleichen Maschine in 1 oder 2 VMs) ...

Aber mit 100 User und 47GB DB sind 32GB RAM einfach wenig, das ist sicher.
Und wenn der einfache Weg ist erst mal mehr RAM reinzustecken zu geringen Kosten, dann würde ich das tun.

Warum sich die DB nicht die Daten reinsaugt, den RAM nutzt so intensiv wie möglich, Indexe und häufige Daten (Stammdaten, etc.) permanent vorhält ? Fragezeichen.
In Zeiten von SSD wie viel Relevanz hat das noch ?
Daten im RAM werden von der Software verworfen, physisch neu gelesen, ohne echten Sinn ?

Einfacher wurde es nicht in den letzten 20 Jahren, alte DBs waren einfacher gestrickt, auch relationale DBs, aber dann noch zu komplexe Betriebssysteme und Virtualisierungen die heute reinspucken oder RAID-Software / Hardware.

Wie schön war ein DB-Server, wenn RAM oder CPU auf Auslastung gingen (in Spitzenzeiten) wurde einfach Hardware nachgeschoben damit die Werte wieder sinken.


Hast du mal versucht die DB lokal auf einem PC zu installieren, einem PC um die 1.000 Euro von der Stange (64GB RAM, ordentliche CPU, 2 x SSD, Windows 10, einfache Grafikkarte) und dann als Single-User getestet wie schnell die WAWI ist im Vergleich zur Live-Installation ist ?
Wenn kein Unterschied da ist, dann nützt alles nix, liegt an der WAWI, DB-Größe Anzahl Artikel, Kunden, Aufträge .... Optimierungsbedarf seitens JTL.
Wenn ein merklicher Unterschied ist, dann hakt es irgendwo am Server.

So ein Test (mit kostenloser Entwickler-Lizenz der DB) kostet nicht alle Welt, kann dir aber helfen ...

SG

PS: Mich würde das Ergebnis auch interessieren.
 
  • Gefällt mir
Reaktionen: mh1

mh1

Sehr aktives Mitglied
4. Oktober 2020
435
90
  • Hyper-V und nur die Wawi draufpacken? Warum das? Wie gesagt: der Host langweilt sich, sowohl RAM als auch CPU technisch...
    • CPU technisch würde mich mal interessieren, welchen Effekt bei den ~100 concurrent connections eine höhere Single Thread Performance (sprich schnellere Kerne) oder eben mehr Cores haben..
So etwas kann Lizenzgründe haben. Wenn der Host z.b. 16 Kerne hat und man hat aber nur eine 4 Core Lizenz 🤔
 
  • Gefällt mir
Reaktionen: MichaelH

mvh

Sehr aktives Mitglied
26. Oktober 2011
430
107
Moin.
Ich kann Euch keine Vorschläge machen, aber so würde ich vorgehen.

Als erstes würde ich über Ressourcen-Monitor / SQL Server Profiler den "Flaschenhals" suchen.
s. z.B. https://www.mssqltips.com/sqlservertip/6945/windows-performance-monitor-counters-for-sql-server/
Sobald das "Problem" identifiziert ist - weitere Schritte planen, und nicht in "alle Richtungen" wie gerade gehen.

Bei 32 GB habt ihr ca. 5,8 GB für "cached plans", unsere WaWi verbraucht ca. 4,5 GB (die Anzahl liegt bei ca. 113K),
da bleibt bei Euch noch ca. 18 GB für den "Rest", ist vielleicht nicht viel, sollte aber ausreichend sein.

Ich würde fast vorgeschlagen ernsthaft über HA/Clustering/Always On nachzudenken, um die Netzwerklast zu verteilen/verringern
aber das wird wiederum kostspielig.

Viele Grüße, Ihr MVH-Team
 
  • Gefällt mir
Reaktionen: MichaelH

MichaelH

Sehr aktives Mitglied
17. November 2008
13.206
1.243
"Bei 32 GB habt ihr ca. 5,8 GB für "cached plans", unsere WaWi verbraucht ca. 4,5 GB (die Anzahl liegt bei ca. 113K),
da bleibt bei Euch noch ca. 18 GB für den "Rest", ist vielleicht nicht viel, sollte aber ausreichend sein."

Ein Mann mit aktuellem Wissen, das klingt schon mal gut ! :thumbsup:
 

bbtd

Neues Mitglied
29. August 2022
7
0
Hast du mal versucht die DB lokal auf einem PC zu installieren, einem PC um die 1.000 Euro von der Stange (64GB RAM, ordentliche CPU, 2 x SSD, Windows 10, einfache Grafikkarte) und dann als Single-User getestet wie schnell die WAWI ist im Vergleich zur Live-Installation ist ?
Interessante Herangehensweise: Was genau sagt so ein Test denn aus und was kann man damit für die Produktiv-Installation ableiten?
→ Single User mit DB auf localhost vs. SQL Server im Netzwerk mit 100 concurrent connections.

Auch die Hardware kann man mNm nicht vergleichen:
Intel XEON bzw. AMD Epic CPUs vs. Intel/AMD Desktop CPUs (CPU Cache + ECC RAM), GPU ist nicht notwendig und beim Storage kommt es doch sehr auf die IOPS und die Latenz an: (SATA SSD vs. PCIe NVMe)

-----------------------------
Wir schweifen aber hier auch ab - ich möchte eigentlich keine Grundsatzdiskussion antreten, sondern mir geht es um Optimierungspotential der vorhandenen Umgebung.
→ Passen die Settings oder gibt es hier noch Potential (siehe Post #1 + #9), oder brauchen wir für mehr Performance andere bzw. bessere Hardware?
 

MichaelH

Sehr aktives Mitglied
17. November 2008
13.206
1.243
Erläutert habe ich es ...

Und ich vermute du wärst in einem SQL-DB-Forum besser aufgehoben als hier, da hier so gut wie niemand 100 User mit 47GB DB hat und wenn dann liest dieser vermutlich nicht im Forum, sondern hat DB-Profis am Werk, denn du bist offensichtlich keiner.
 
  • Gefällt mir
Reaktionen: mvh

mh1

Sehr aktives Mitglied
4. Oktober 2020
435
90
Bei 32 GB habt ihr ca. 5,8 GB für "cached plans", (...)
Ich habe auch schon Admins kennenelernt, die mit dem entsprechenden Trace Flag den Plan Cache vergrößern. Bei 32GB dann auf ca. 16GB.
Aber das nur am Rande, weil man in dem Fall schon gaaaanz genau wissen sollte was man tut und im Hinblick auf JTL kann man ja sowieso nicht 100%ig einsehen, was wann wo wie abläuft.
 

mh1

Sehr aktives Mitglied
4. Oktober 2020
435
90
Interessante Herangehensweise: Was genau sagt so ein Test denn aus und was kann man damit für die Produktiv-Installation ableiten?
Du hast recht, dass du damit in keiner Weise ein vergleichbares System aufbaust.
Aber ein solcher Test könnte dir z.b. dabei helfen, die subjektive Einschätzung aus #1, dass "die Wawi langsam sei" neu einzuordnen.
Du könntest dann auch z.b. die Kollegin aus dem Verkauf einfach mal für eine Viertelstunde in dieser lokalen Installation rumklicken lassen.

Ich habe hier im Haus schon bei mehreren Programmen, solche Tests aufgebaut, die ja - da hast du recht - keine wirklich vergleichenden Tests sind (und aber auch nicht sein sollen).

Unter Umständen bekommt man dann aber schonmal einen ganz guten Eindruck von dem, was überhaupt möglich sein könnte und an welchen stellen sich das genauere hinsehen lohnen könnte.
Damit kann man auch schonmal eine ganz gute Hilfestellung für denjenigen schaffen, der dann entscheidet, ob und mit welcher Priorität sich der Admin in die Optimierung der Wawi einbinden soll.
 
  • Gefällt mir
Reaktionen: MichaelH

MichaelH

Sehr aktives Mitglied
17. November 2008
13.206
1.243
Lokales System ist erheblich schneller - dann hast du wohl deinen Server vermurkst
Lokales System ist gleich schnell - dann wird nicht viel zu machen sein ohne Hilfe von JTL (SQLs sind auf die Tabellengrößen / Datenmengen nicht optimiert)
Lokales System ist erheblich langsamer - dann hast du deine Server-Arbeit schon gut gemacht

Und den Vergleich auch mal am Wochenende machen, wenn der Server nichts zu tun hat.

Z.B. schon wenige SQLs die falsch laufen und schlimmstenfalls sogar temporäre Keys aufbauen, können die Arbeit für die User verlangsamen und das merkt man eben erst, wenn man größere Datenmengen hat.
Es gibt aber sicherlich auch ein Tool das der Fachmann dafür verwendet.
 
  • Gefällt mir
Reaktionen: mh1

mvh

Sehr aktives Mitglied
26. Oktober 2011
430
107
Ich habe auch schon Admins kennenelernt, die mit dem entsprechenden Trace Flag den Plan Cache vergrößern. Bei 32GB dann auf ca. 16GB.
Aber das nur am Rande, weil man in dem Fall schon gaaaanz genau wissen sollte was man tut und im Hinblick auf JTL kann man ja sowieso nicht 100%ig einsehen, was wann wo wie abläuft.
Ja, mit dem Trace-Flag (Vermutlich 8032) kann man bis zu 17GB gehen,
s. https://www.sqlskills.com/blogs/erin/sql-server-plan-cache-limits/
https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc293624(v=technet.10)
https://docs.microsoft.com/en-us/sq...race-flags-transact-sql?view=sql-server-ver16
aber wie ich geschrieben habe - ist bei der WaWi (1.5/1.6) gar nicht notwendig.
Die WaWi leidet an Datenfragmentierung, langsamen Abfragen, Deadlocks - aber das ist ein Thema für sich.
 

mh1

Sehr aktives Mitglied
4. Oktober 2020
435
90
Genau. Deshalb hatte ich das TraceFlag auch nicht näher benannt.
Damit nicht einer auf die Idee kommt und spielt mit solchen Dingen rum, ohne genauere Kenntnis der Sache.
 
Ähnliche Themen
Titel Forum Antworten Datum
Welcher SQL Server für Version 1,7 ? JTL-Wawi 1.7 5
Neu Direkte SQL Abfrage auf den SQL Server JTL Ameise - Eigene Exporte 8
Neu JTL WAWI auf Ubuntu 20.04 mit MS-SQL-Server-2019 Installation von JTL-Wawi 8
Neu SQLState=22003, NativeError=0, Message=[Microsoft][ODBC SQL Server Driver]Numerische Werte außerhalb des zulässigen Bereichs JTL-Wawi - Fehler und Bugs 0
Neu Import Datenbank funktioniert nicht - SQL Server 2017 / 2019 User helfen Usern - Fragen zu JTL-Wawi 2
Neu eComData Shared SQL Server Standard - jemand Erfahrungen damit? User helfen Usern - Fragen zu JTL-Wawi 21
Neu Kleiner, reiner SQL 2019 Standard Server - Günstige Fujitsu PRIMERGY TX1310 M3 OK? User helfen Usern - Fragen zu JTL-Wawi 14
Neu JTL Datenbank von SQL Server 2017 in 2019 einbinden User helfen Usern - Fragen zu JTL-Wawi 13
Neu Lizensierung SQL Server User helfen Usern - Fragen zu JTL-Wawi 7
Neu SQL Konfig - Raid ja oder nein? Installation von JTL-Wawi 20
Neu JTL Ameise Eigener SQL Export via Batch Datei User helfen Usern - Fragen zu JTL-Wawi 2
Neu SQL Error -1 preforming exec nach Windows Update JTL-Wawi - Fehler und Bugs 2
Neu Hilfe benötigt, SQL Fehler nach Windows update User helfen Usern - Fragen zu JTL-Wawi 15
Neu Haken bei Bilder für bestimmte Plattform via SQL-Befehl bei Kindartikel entfernen User helfen Usern - Fragen zu JTL-Wawi 3
Neu SQL Fehler im Logbuch JTL-Shop - Fehler und Bugs 3
Neu Backend - Logbuch: SQL - Fehler JTL-Shop - Fehler und Bugs 2
Neu SQL-Afrage: Eigene Felder User helfen Usern - Fragen zu JTL-Wawi 10
Neu SQL-Abfrage Kunden Historie mehr Information User helfen Usern - Fragen zu JTL-Wawi 1
Neu Feature Request: Eigner SQL als Temporärer Filter für Artikelliste JTL-Wawi - Ideen, Lob und Kritik 0
Neu Timeout bei Aufruf des 5.1.2 Shops / SQL Query blockiert anderes Queries JTL-Shop - Fehler und Bugs 5
Neu Berechnung des Datumsunterschieds in der SQL-Abfrage User helfen Usern 2
Neu Workflow SQL benötige eure Hilfe User helfen Usern - Fragen zu JTL-Wawi 14
Neu SQL Abfrage erstellen für Kunden "Shopregistrieung" User helfen Usern - Fragen zu JTL-Wawi 4
Neu SQL - Datenabfrage FBA (Bestände) Schnittstellen Import / Export 5
Neu ebay Angbeot per SQL beenden eBay-Anbindung - Ideen, Lob und Kritik 2
Neu Shop SQL-Injection Sicherheitslücke - Patch drauf und gut ist? Sonst keine Maßnahmen? Betrieb / Pflege von JTL-Shop 11
Neu Wie lautet der SQL Befehl zum löschen der Kommentare? User helfen Usern - Fragen zu JTL-Wawi 4
Beantwortet JTL1.6 Wo finde ich die Lieferadresse in der SQL DB ? User helfen Usern - Fragen zu JTL-Wawi 9
Neu SQL Befehle -Hilfe JTL-Ameise - Ideen, Lob und Kritik 10
Performance Unterschiede SQL Express und Standard JTL-Wawi 1.6 23
Neu SQL Abfrage JTL 1.5 Menge im Lieferschein Schnittstellen Import / Export 2
Beantwortet Frage: SQL Select Eigene Felder eines Kunden User helfen Usern - Fragen zu JTL-Wawi 6
Neu Fehler Datenbankimport auf neuen Server Installation von JTL-Wawi 1
Neu jQuery-Problem nach Server-Wechsel Installation / Updates von JTL-Shop 0
Neu ecoDMS Rechnungen von Clientsystemen zum ecoDMS Server bringen User helfen Usern - Fragen zu JTL-Wawi 2
Wichtig Wartungsarbeiten am JTL-Track&Trace Server JTL-Track&Trace - Ideen, Lob und Kritik 0
Neu JTL Shop 5 mit externem Redis Server nutzen Allgemeine Fragen zu JTL-Shop 5
Neu 02.09.2022 JTL-Shipping The remote server returned an error: (502) Bad Gateway JTL-ShippingLabels - Fehler und Bugs 35
Neu Umstellung von Server auf Einzelplatz Installation von JTL-Wawi 1

Ähnliche Themen