Sage 100 Applikationsserver: So holst Du das Maximum an Performance raus

Wir erleben es in fast jedem Projekt: Nach einer gezielten Optimierung des Applikationsservers sind unsere Kunden überrascht, wie viel schneller ihre Sage 100 plötzlich läuft. Berichte, die vorher gefühlt ewig brauchten, sind in Sekunden da. Das Erfassen von Aufträgen flutscht. Und morgens beim Anmelden muss niemand mehr warten. Das Beste daran: Die Stellschrauben sind gar nicht so kompliziert. Hier zeigen wir Dir, worauf es ankommt.

Warum der Applikationsserver so entscheidend ist

Der Applikationsserver ist das Herzstück jeder Sage 100 Installation. Er verarbeitet die Anfragen aller Clients, stellt Berichte zusammen und koordiniert den Zugriff auf die Datenbank. Wenn er optimal eingestellt ist, merken Deine Anwender davon nichts. Alles fühlt sich einfach schnell und flüssig an. Und genau das ist unser Ziel.

Schritt 1: Arbeitsspeicher großzügig planen

Der mit Abstand wirkungsvollste Hebel ist ausreichend RAM. Die meisten Systeme, die wir bei Kunden vorfinden, sind hier zu knapp bemessen. Dabei macht der richtige Arbeitsspeicher einen gewaltigen Unterschied, und die Investition ist überschaubar.

Die Faustregel für die Berechnung:

• Betriebssystem: 8 GB (realistischer Wert für einen Windows Server)
• Applikationsserver: pro Benutzer ca. 300 MB, dazu 150 MB für den asynchronen Druck
• SQL-Server (falls auf dem gleichen Rechner): mindestens so viel RAM wie die Datenbank groß ist

Klingt nach viel? Relativiert sich schnell. Im Durchschnitt nutzt etwa jeder siebte Anwender das System gleichzeitig. Bei 25 Benutzern brauchst Du also rund 8 GB für den Applikationsserver. Ab 35 Benutzern rechnest Du pro 10 weitere Nutzer jeweils 1 GB dazu.

Schritt 2: SSD für den BlobStorage

Das ist eine unserer Lieblingsoptimierungen, weil der Effekt sofort spürbar ist. Beim Drucken von Berichten und Auswertungen schreibt der Applikationsserver temporäre Dateien auf die Festplatte, den sogenannten BlobStorage. Wenn diese Dateien auf einer langsamen HDD landen, bremst das den gesamten Druckprozess.

Lege das BlobStorage-Verzeichnis auf eine eigene SSD und Du wirst den Unterschied sofort merken. Keine riesige Platte nötig: 100 GB reichen locker, weil die temporären Dateien nach kurzer Zeit automatisch gelöscht werden.

Derselbe Trick funktioniert auch auf Terminalservern. Dort werden die Druckdateien ebenfalls zwischengespeichert. Eine SSD am Terminalserver ist ein oft übersehener Quick Win.

Schritt 3: SQL-Server Festplatten trennen

Wenn der SQL-Server auf demselben Rechner läuft, lohnt sich ein Blick auf die Festplattenstruktur. Idealerweise liegen diese Dateien auf getrennten Laufwerken:

• Datenbankdateien (.mdf)
• Protokolldateien (.log)
• tempdb (SQL-Systemdatenbank)

Bei klassischen HDDs bedeuten getrennte Laufwerke auch getrennte Schreib- und Leseköpfe, was bei gleichzeitigen Zugriffen einen großen Unterschied macht. Aber auch mit SSDs oder NVMe-Laufwerken lohnt sich die Trennung: Jedes Laufwerk hat seinen eigenen Controller und eigenen I/O-Kanal. Unter Last vermeidest Du so Engpässe, die entstehen, wenn Datenbank, Logs und tempdb um dieselbe Bandbreite konkurrieren. Bei unseren Kunden sorgt allein diese Maßnahme regelmäßig für spürbar schnellere Datenbankabfragen.

ServiceDomains richtig konfigurieren

Hier steckt oft das größte Optimierungspotenzial und gleichzeitig der Grund, warum viele Installationen unnötig langsam sind. Die Standardwerte passen für kleine Umgebungen, aber nicht für den realen Betrieb mit vielen Anwendern. Die Konfiguration findest Du in der Datei Sagede.ApplicationServer.Core.config.

Die wichtigsten Parameter:

• contextQuotaMax: Wie viele parallele Anfragen ein Benutzer stellen darf. Standard ist 2 (Client + Auskunft). Erhöhst Du den Wert, steigt auch der RAM-Bedarf pro User.
• poolInitialSize: Wie viele ServiceDomains beim Start bereitstehen. Großzügig setzen, damit morgens beim Anmelden alles sofort reagiert.
• poolMaxSize: Maximale Anzahl freier Prozesse, bevor aufgeräumt wird. Faustregel: doppelte Anzahl der Benutzer.
• poolMinSize: Sobald weniger als diese Anzahl frei ist, werden neue Prozesse erzeugt.

Mehrere Applikationsserver und Load Balancing

Ab einer gewissen Unternehmensgröße lohnt sich der Betrieb mehrerer Applikationsserver. Die Sage 100 unterstützt das mit einer Art Load Balancing: Das System leitet jeden Benutzer automatisch wieder auf den Server, auf dem er zuvor gearbeitet hat. So wird eine bereits vorhandene ServiceDomain wiederverwendet und der Zugriff wird nochmal schneller.

Die Steuerung erfolgt über das CapabilityFlag in der Konfiguration:

• Flag 1: Server nimmt am Load Balancing teil (Normalbetrieb)
• Flag 2: Server stellt Metadaten bereit (AppDesigner-Entwicklung)
• Flag 0: Server nimmt nicht am Load Balancing teil (eigene Services)

Performance messen und Erfolge sichtbar machen

Nach der Optimierung willst Du natürlich wissen, was sie gebracht hat. Windows liefert mit perfmon das passende Werkzeug. Die wichtigsten Leistungsindikatoren:

• ServiceDomains: Gesamtanzahl der verfügbaren ServiceDomains
• ActiveServiceDomains: Anzahl der gerade aktiven Anfragen
• ServiceDomainsCreationRejected: Fehlgeschlagene Versuche, neue ServiceDomains zu erzeugen (Hinweis auf RAM-Engpass)
• RejectedServiceCalls: Zurückgewiesene Anfragen wegen Überlastung

Wir empfehlen, diese Werte einmal unter Volllast zu messen und als Referenz zu speichern. So hast Du eine saubere Vergleichsbasis und kannst bei Bedarf gezielt nachjustieren.

Fazit

Die meisten Sage 100 Installationen verschenken Performance, weil sie mit Standardeinstellungen laufen. Dabei reichen oft ein bis zwei Stunden Arbeit, um das System spürbar schneller zu machen. Ausreichend RAM, SSDs an den richtigen Stellen und eine durchdachte ServiceDomain-Konfiguration: Das sind die drei Hebel, die den größten Unterschied machen.

Bei unseren Kunden hören wir danach regelmäßig: „Warum haben wir das nicht früher gemacht?" Gute Frage. Lass uns loslegen.