Sage 100 · Applikationsserver

Sage 100 schnell – auch oberhalb der Datenbank

Der SQL Server reagiert schnell, aber Sage 100 trotzdem nicht? Dann endet die Performanceanalyse nicht an der Datenbank.

Wir messen, wie der Sage-100-Applikationsserver Requests verarbeitet, ServiceDomains bereitstellt und Ressourcen unter echter Last verteilt.

ServiceDomainsPoolingPerformance CounterETW & TracingBlobStorageLoad Balancing
Applikationsserver prüfen lassen
Erst messenEngpass lokalisierenGezielt konfigurierenWirkung belegen
Die komplette Strecke betrachten

Zwischen Sage-Client und SQL Server liegt mehr als ein Pfeil

Ein Sage-Aufruf durchläuft mehrere technische Ebenen. Erst wenn wir die Zeit entlang dieser Strecke trennen, wird aus „Sage ist langsam“ eine belastbare Diagnose.

Sage ClientBenutzeraktion und Kontext
→
ApplikationsserverServiceDomains · Pooling · Businesslogik
→
SQL ServerAbfragen · Waits · Blocking
→
StorageDaten · Log · Dateien
DatenbankebeneIst die SQL-Verarbeitung langsam?

Wait Statistics, I/O, CPU, RAM, Blocking, Ausführungspläne, Indizes und Statistiken zeigen, wo die Datenbank Zeit verliert.

AnwendungsebeneOder entsteht die Verzögerung davor?

ServiceDomain-Verfügbarkeit, Initialisierung, parallele Requests, Businesslogik, Dienste und Netzwerk können bereits vor dem SQL-Aufruf warten.

SQL-Performance-Check ergänzen

ServiceDomains verstehen

Eine passende Sage-Instanz für jede Anfrage

Eine ServiceDomain verbindet Service, initialisierte Sage-Anwendung und Anwendungskontext in einer isolierten Laufzeitumgebung. Deshalb passt nicht jede vorhandene Domain zu jedem Request.

BenutzerWer stellt die Anfrage?
DatenquelleWelche Umgebung wird verwendet?
MandantIn welchem Kontext läuft der Prozess?
Applikationsserver · Live-ModellServiceDomain-Pool
Beleg öffnenRequest A
Auskunft startenRequest B
Report erzeugenRequest C
SchnittstelleRequest D
Aktiv · verarbeitet gerade
SD 01aktiv
SD 02aktiv
SD 03aktiv
Pool · vorbereitet und verfügbar
SD 04bereit
SD 05bereit
SD 06bereit
SD 07wird erzeugt
Vorbereitete Kapazität verkürzt Wartezeiten. Zu viel Reserve bindet unnötig Ressourcen.
Pooling richtig dimensionieren

Drei Poolgrößen – eine gemeinsame Kapazitätsentscheidung

ServiceDomain-Pooling ist kein Satz unabhängiger XML-Schalter. Initialbestand, Mindestreserve, Obergrenze und Lebensdauer greifen ineinander.

poolInitialSizeKapazität beim Start

Wie viele ServiceDomains werden vorgeladen, bevor morgens viele Benutzer gleichzeitig beginnen?

poolMinSizeReserve nachproduzieren

Sinkt der vorbereitete Bestand, kann der Server im Hintergrund neue Domains erzeugen.

poolMaxSizeUngenutzte Reserve begrenzen

Verhindert, dass einmal aufgebaute Kapazität dauerhaft unbegrenzt RAM bindet.

lifeTimeLeaseTimeLebensdauer steuern

Zu kurze Werte erzeugen unnötigen Neuaufbau, zu lange Werte halten Ressourcen fest.

contextQuotaMaxKontexte fair begrenzen

Ein einzelner Client soll nicht alle verfügbaren Verarbeitungsslots belegen.

maxActiveServiceDomainsParallelität kontrollieren

Mehr gleichzeitige Prozesse helfen nur, solange CPU, RAM und Gegensysteme mithalten.

Zu klein

Häufige Initialisierung, knappe Reserve und Wartezeit bei typischen Spitzen.

Passend zur Last

Genügend vorbereitete Domains bei kontrolliertem Ressourcenverbrauch.

Zu groß

Unnötig gebundener RAM und Konkurrenz zu SQL Server und Betriebssystem.

Nicht Benutzer zählen, Last messen

30 Lizenzen bedeuten nicht 30 gleich aktive Prozesse

Arbeitsbeginn, Rückkehr aus Pausen, Massendruck, Reporting und Hintergrundjobs erzeugen eigene Lastprofile. Genau diese Spitzen entscheiden über die sinnvolle Reserve.

Beispielhafter Tagesverlaufrelative Parallelität · keine Messwerte eines Kundensystems
07
08
09
10
11
12
13
14
15
16
17
08:00 · Anmeldung10:00 · Reporting13:00 · Rückkehr aus Pauselaufend · Schnittstellen & Jobs

Ohne passende Begrenzung

Benutzer A
Benutzer B
Benutzer C

Fair verteilte Parallelität

Benutzer A
Benutzer B
Benutzer C
Zeit sauber trennen

SQL schnell + Sage langsam = oberhalb der Datenbank messen

Wenn eine SQL-Abfrage 80 ms benötigt, der komplette Sage-Aufruf aber 2.400 ms, erklärt die Datenbank nur einen kleinen Teil der wahrgenommenen Laufzeit.

Beispielhafter Sage-AufrufGesamtzeit 2.400 ms
SQL-Verarbeitung
80 ms
Restliche Prozesskette
2.320 ms
Die Differenz kann in Domain-Suche, Initialisierung, Businesslogik, Kommunikation, Dateizugriffen, Services oder individuellen Erweiterungen entstehen.
Messwerte aus dem Server

Performance Counter zeigen, was unter Last tatsächlich passiert

Einzelne Werte sind keine Diagnose. Erst ihr gemeinsamer Verlauf zeigt, ob der Server hohe Last gesund verarbeitet oder ob Requests bereits auf Kapazität warten.

Application Server · Performance Monitor● MESSUNG AKTIV
ActiveServiceDomainsAktive Verarbeitung

Wie viele Domains gerade Requests ausführen.

ServiceDomainPoolSizeVorbereitete Reserve

Wie viele passende Domains im Pool bereitstehen.

FindChannelTimeDomain-Suche

Zeit bis eine geeignete freie Domain gefunden wird.

ProcessMessageTimeBusinesslogik

Verarbeitungszeit der gehosteten Anwendung.

TotalProcessMessageTimeGesamtaufruf

Durchschnittliche Dauer eines vollständigen Aufrufs.

RejectedServiceCallsAbgewiesene Requests

Aufrufe, die wegen hoher Last nicht angenommen wurden.

ServiceCallsPerSecondDurchsatz

Verarbeitete Serviceaufrufe pro Sekunde.

AsyncQueuedRequestsWarteschlange

Asynchrone Anforderungen, die noch warten.

ActiveServiceDomains hochallein noch kein Problem
+
RejectedServiceCalls steigenKapazitätsgrenze sichtbar
+
FindChannelTime steigtfreie Domain wird knapp
Gesamtsystem statt Einzelwert

Application-Server-Performance ist mehr als RAM

Applikationsserver und SQL Server können auf demselben System betrieben werden. Dann konkurrieren beide jedoch mit Windows und weiteren Diensten um dieselben Ressourcen.

CPUParallelität

Wie viele Prozesse können wirklich effizient gleichzeitig laufen?

RAMServiceDomains

Wie viel Reserve ist sinnvoll, ohne SQL Buffer Pool zu verdrängen?

NetzwerkKommunikation

Wie schnell erreichen Clients, Dienste und Datenbank einander?

StorageDateizugriffe

Wo liegen Blob-, temporäre und dienstbezogene Daten?

SQL ServerBusinessdaten

Wie schnell beantwortet die Datenbank ausgelöste Abfragen?

Eine hohe Speichernutzung ist ein Messwert. Ob sie sinnvoll oder problematisch ist, entscheidet der Kontext.
Baseline und Tiefendiagnose

Unter realer Last messen – sporadische Fehler gezielt tracen

Eine Messung am Sonntag erklärt keine Engpässe am Montagmorgen. Wir zeichnen den normalen Arbeitstag auf und vertiefen auffällige Zeitfenster bei Bedarf mit ETW und TraceLogManager.

Problem konkretisieren
→
Baseline aufzeichnen
→
Trace gezielt erfassen
→
Logging normalisieren
Performance CounterDass etwas passiert

Last, Poolgröße, Wartezeit, Durchsatz und abgewiesene Requests über den relevanten Zeitraum.

TracingWas genau passiert

Technische Ereignisse bei sporadischen Fehlern, fehlgeschlagenen Requests, Updates oder Authentifizierungsproblemen.

Dauerhaft maximale Protokollierung ist keine Monitoringstrategie – sie erzeugt selbst Last und große Datenmengen.
Dienste sicher betreiben

BlobStorage, STS und Endpunkte gehören zur Prozesskette

Nach Update, Servermigration, Namens- oder Zertifikatswechsel reicht „der Hauptdienst startet“ nicht. Entscheidend ist, ob die gesamte beteiligte Dienstlandschaft funktioniert.

Daten & Services

BlobStorageSData- und SOAP-EndpunkteHintergrund- und Reportprozesse

Identität & Zugriff

Secure Token Service (STS)Servicekonten und BerechtigungenAutorisierung und Endpunktkonfiguration

Transport & Zertifikate

SSL und PortbindungThumbprint und ZertifikatsspeicherGültigkeit, DNS-Namen und Protokolle
Performanceoptimierung darf nicht zulasten der Sicherheit gehen. Veröffentlichte Endpunkte und Kommunikation über Netzwerkgrenzen werden verschlüsselt und nachvollziehbar konfiguriert.
Gezielt skalieren

Ein zweiter Applikationsserver ist keine Universalmedizin

Mehrere Instanzen und Load Balancing können bei hoher paralleler Service-Last sinnvoll sein. Sie beschleunigen jedoch weder eine langsame SQL-Abfrage noch einen schlecht entwickelten Report.

Sage ClientsBenutzer und Anwendungskontext
→
Clientseitige Verteilungpassende Instanz und Wiederverwendung
→
App Server AClient-Services
App Server Bspezielle Capability
Erst Engpass bestimmen. Dann Kapazität oder Rollenverteilung erweitern.
Typische Ausgangslagen

Wann sich ein Application Server Check lohnt

Arbeitsbeginn„Sage ist morgens besonders langsam.“

Pooling, Preloading, ServiceDomain-Erzeugung und Lastverlauf zusammen prüfen.

Reporting„Reports brauchen plötzlich sehr lange.“

Datenbanklaufzeit, Businesslogik, asynchrone Verarbeitung und BlobStorage trennen.

Update„Nach dem Update starten Dienste nicht.“

Dienstkonfiguration, STS, Zertifikate, Endpunkte und Konfigurationsdateien analysieren.

Ressourcen„Der Server benötigt sehr viel RAM.“

Anzahl und Lebensdauer der Domains in Relation zur wirklichen Last bewerten.

Überlastung„Requests werden abgewiesen.“

Parallelitätsgrenzen, Context Quotas, Pooling und Rejected-Counter korrelieren.

Skalierung„Wir planen einen zweiten Server.“

Vorher belegen, ob Verteilung das vorhandene Problem tatsächlich löst.

Keine Standardwerte aus dem Internet

Dokumentation erklärt den Parameter – Ihre Last bestimmt den Wert

Eine Empfehlung wie poolInitialSize = 20 kennt weder Ihre Benutzer, CPU, RAM, Mandanten, Reports, Schnittstellen noch Lastspitzen.

Dokumentationtechnische Wirkung
+
Hardwareverfügbare Ressourcen
+
Nutzungsprofilechte Parallelität
=
Begründete Konfigurationmessbar und dokumentiert
Unser Application Server Check

Vom Ist-Zustand zur kontrollierten Optimierung

1Architektur aufnehmen

Version, Benutzer, Server, Terminalserver, Reporting, APIs, Zusatzlösungen und Schnittstellen.

2Ressourcen analysieren

CPU, RAM, Storage, Windows, Virtualisierung und konkurrierende Prozesse.

3Pooling prüfen

Initial-, Mindest- und Maximalgröße, Lebensdauer, Quotas und Parallelitätsgrenzen.

4Counter messen

ServiceDomains, Pool, Zeiten, Durchsatz, Warteschlangen und Ablehnungen.

5Tracing vertiefen

ETW, TraceLogManager, Ereignisprotokolle und Sage-Logs gezielt einsetzen.

6Dienste prüfen

BlobStorage, STS, Zertifikate, Servicekonten und Endpunkte einbeziehen.

7SQL gegenprüfen

Datenbanklaufzeit von Wartezeit in Anwendung und Infrastruktur trennen.

8Wirkung belegen

Änderung im Wartungsfenster umsetzen und dieselbe Lastsituation erneut messen.

BereichBewertungPriorisierte Maßnahme
Pool Initial SizekritischAuf gemessene Morgenlast anpassen
Context QuotarelevantParallelität unter Last validieren
Rejected Callsin OrdnungKeine Änderung
FindChannelTimeauffälligDomain-Verfügbarkeit untersuchen
ProcessMessageTimeauffälligBusinesslogik und SQL vertiefen

Beispielhafte Darstellung der Auswertung – keine pauschale Konfigurationsempfehlung.

Warum Appontes?

Sage-Prozess und technische Plattform zusammen denken

Sage 100 verstehen

Wir betrachten nicht nur die Oberfläche, sondern die Geschäftslogik hinter Services und Requests.

ServiceDomains einordnen

Pooling, Wiederverwendung, Ressourcenbedarf und Parallelität werden technisch verstanden.

SQL Server mitmessen

Die Analyse endet nicht am Applikationsserver, wenn Messwerte auf die Datenbank zeigen.

Code bewerten

Eigene Abfragen, Dienste, Schnittstellen und Zusatzlösungen können getrennt untersucht werden.

Werkzeuge beherrschen

Performance Monitor, ETW, TraceLogManager, Event Log, SQL-DMVs und Query Store.

Änderungen dokumentieren

Ist-Zustand, Hypothese, Wartungsfenster, Funktionstest und Vorher-Nachher-Wirkung bleiben nachvollziehbar.

Nicht nach Bauchgefühl konfigurieren

Sage 100 Applikationsserver professionell prüfen

Wir zeigen, ob Zeit bei ServiceDomains, Businesslogik, Diensten, Infrastruktur oder SQL Server verloren geht – und welche Änderung nachweisbar hilft.

ServiceDomainsPoolingPerformance CounterETWBlobStorageSTSSQL Server
Application Server Check anfragen
FAQ

Häufig gestellte Fragen

Was macht der Sage 100 Applikationsserver? +
Er stellt die Laufzeitumgebung bereit, in der Services parallel gegen die Sage-100-Geschäftslogik ausgeführt werden. Dafür verwendet er isolierte Anwendungsinstanzen in sogenannten ServiceDomains.
Was ist eine ServiceDomain? +
Eine ServiceDomain kombiniert einen Service mit einer initialisierten Sage-Anwendungsinstanz und einem bestimmten Anwendungskontext in einer isolierten Laufzeitumgebung.
Warum werden ServiceDomains gepoolt? +
Die vollständige Initialisierung benötigt Zeit und Ressourcen. Vorbereitete ServiceDomains können deshalb im Pool vorgehalten und für passende Anfragen wiederverwendet werden.
Was bedeuten poolInitialSize, poolMinSize und poolMaxSize? +
Sie steuern die beim Start vorbereitete Anzahl, die nachzuladende Mindestreserve und die maximale Zahl ungenutzter ServiceDomains im Pool. Die Werte müssen gemeinsam betrachtet werden.
Sollte man die Poolgrößen möglichst hoch einstellen? +
Nein. Zu kleine Pools können Wartezeiten durch Initialisierung verursachen, zu große Pools binden unnötig Arbeitsspeicher. Entscheidend sind reale Parallelität und Lastspitzen.
Was begrenzt contextQuotaMax? +
Der Parameter begrenzt, wie viele Requests desselben Anwendungskontexts parallel ausgeführt werden dürfen und kann so zu einer faireren Ressourcenverteilung beitragen.
Wie lässt sich die Auslastung messen? +
Der Applikationsserver stellt eigene Windows Performance Counter bereit, unter anderem für aktive ServiceDomains, Poolgröße, Such- und Verarbeitungszeit, Durchsatz und abgewiesene Aufrufe.
Was ist FindChannelTime? +
Der Counter beschreibt, wie lange die Infrastruktur durchschnittlich benötigt, um eine passende freie ServiceDomain zu finden.
Was bedeutet RejectedServiceCalls? +
Der Counter zählt Requests, die wegen hoher Last zurückgewiesen wurden. Steigt er an, müssen Kapazität, Parallelitätsgrenzen und die Ursache der langen Verarbeitung untersucht werden.
Hilft ein zweiter Applikationsserver immer? +
Nein. Wenn SQL Server, Storage oder eine einzelne Funktion der Engpass sind, verteilt ein zusätzlicher Applikationsserver nur mehr Requests auf dieselbe begrenzende Komponente.
Was ist der TraceLogManager? +
Der TraceLogManager ist ein Sage-Werkzeug zur Anzeige und Verwaltung von Tracinginformationen, beispielsweise von ETW-Ereignissen des Applikationsservers.
Soll detailliertes Logging dauerhaft aktiv bleiben? +
In der Regel nicht. Sehr ausführliches Logging erzeugt selbst Last und große Datenmengen. Es sollte gezielt zur Reproduktion und Analyse eines Problems aktiviert werden.
Unterstützt Appontes auch bei Problemen nach einem Update? +
Ja. Dazu gehören unter anderem nicht startende Dienste, ServiceDomain-Erzeugung, STS, Zertifikate, BlobStorage, SData-, SOAP- und andere Endpunkte.
Wird der SQL Server mitgeprüft? +
Wenn Messwerte oder Symptome auf die Datenbank hinweisen, kann der Application Server Check mit dem Sage-100-SQL-Performance-Check kombiniert werden.