Im Folgenden finden Sie einige Maßnahmen, die Sie ergreifen können, um Performance-Engpässe zu vermeiden oder bestehende Engpässe zu beseitigen.
Gesamtprozesszahl der Anwendung heraufsetzen
Kommt es insbesondere im Dialog-Betrieb bei der Bearbeitung von Aufträgen zu großen Wartezeiten, dann können Sie die Anzahl der Prozesse, in denen das Anwendungsprogramm abläuft, erhöhen.
Dies ist insbesondere dann sinnvoll, wenn die aktuelle Auslastung der Anwendung auf über 80 Prozent ansteigt und gleichzeitig noch genügend Systemressourcen auf dem Rechner frei sind (Speicherplatz, CPU-Leistung). Nach ausreichender Erhöhung der Gesamtprozesszahl sollte sich dieser Wert wieder verringern.
Die erlaubte Maximalzahl der Prozesse wird bei der KDCDEF-Generierung in MAX TASKS festgelegt. Diese Maximalzahl kann administrativ nicht erhöht werden. Ist die momentan eingestellte Prozesszahl jedoch kleiner als diese Maximalzahl, dann können Sie weitere Prozesse für die Anwendung starten.
 | KDCINF SYSPARM: KDCAPPL TASKS: Neue Prozesszahl festlegen |
 | KC_GET_OBJECT mit obj_type=KC_TASKS_PAR: |
Gesamtprozesszahl der Anwendung herabsetzen
Wegen möglicher Lastschwankungen ist es normalerweise nicht sinnvoll, die Gesamtprozesszahl herabzusetzen, wenn die Anwendung zeitweise nicht voll ausgelastet ist.
Die Gesamtprozesszahl sollte nur dann reduziert werden, wenn der Rechner insgesamt in einen Engpass gerät, der eine Verschlechterung des Durchsatzes und/oder der Antwortzeiten der Anwendung bewirkt.
Wenn Sie die Gesamtprozesszahl herabsetzen, müssen Sie Folgendes beachten:
Wird die Gesamtprozesszahl so weit herabgesetzt, dass sie kleiner ist als die aktuell eingestellte Maximalzahl der Prozesse, die gleichzeitig für die Asynchron-Verarbeitung verwendet werden können (im Folgenden ASYNTASKS genannt), dann setzt openUTM den Wert von ASYNTASKS auf die angegebene Gesamtprozesszahl zurück. Bei späteren Änderungen der Gesamtprozesszahl passt openUTM den Wert von ASYNTASKS automatisch an, bis der Wert erreicht ist, der zuvor durch die Administration oder im Startparameter ASYNTASKS eingestellt wurde.
Analoges gilt für die Maximalzahl der Prozesse, in denen gleichzeitig Teilprogramme mit blockierende Aufrufen ablaufen dürfen (TASKS-IN-PGWT). Beachten Sie jedoch, dass die Gesamtprozessanzahl mindestens 2 betragen muss, wenn ein Transaktionscode oder eine TAC-Klasse mit PGWT=YES generiert ist oder wenn es sich um eine UTM-Cluster-Anwendung handelt.
Ist für eine Dialog-TAC-Klasse der Wert von TASKS-FREE größer als die aktuelle Gesamtprozesszahl, dann bearbeitet weiterhin ein Prozess die Aufträge an diese TAC-Klasse.
Wird die Auftragsbearbeitung in der Anwendung über Prioritäten gesteuert (es ist TAC-PRIORITIES generiert) und ist der Wert für FREE-DIAL-TASKS größer als die aktuelle Gesamtprozesszahl, dann bearbeitet weiterhin ein Prozess Aufträge an die Dialog-TAC-Klassen.
Damit der Dialog-Betrieb nach dem Herabsetzen der Gesamtprozesszahl nicht durch langlaufende Asynchron-Vorgänge oder durch Programme mit blockierenden Aufrufen beeinträchtigt wird, sollten Sie die Werte von ASYNTASKS und TASKS-IN-PGWT anpassen, d.h. ebenfalls herabsetzen.
Anzahl der Prozesse herabsetzen, die für Asynchron-Verarbeitung und Bearbeitung von Teilprogrammen mit blockierenden Aufrufen zur Verfügung steht
Wird der Dialog-Betrieb der Anwendung durch zeitintensive Asynchron-Verarbeitung verzögert (Dialog-Aufträge warten, weil zu viele Prozesse gleichzeitig Asynchron-Aufträge bearbeiten), dann können Sie die Maximalzahl der Prozesse (ASYNTASKS) reduzieren, die gleichzeitig für die Asynchron-Verarbeitung verwendet werden können. Damit bleiben mehr Prozesse für die Synchron-Verarbeitung frei. Die Anzahl der Prozesse ASYNTASKS ist durch den in MAX ASYNTASKS generierten Maximalwert beschränkt.
Sie können ASYNTASKS zeitweise auf 0 setzen. Dabei sollten Sie jedoch beachten, dass alle Asynchron-Aufträge im Pagepool zwischengespeichert werden. Ist der Pagepool nicht groß genug dimensioniert, kann es zu Pagepool-Engpässen kommen.
Beim Herabsetzen von ASYNTASKS müssen Sie, wenn in Ihrer Anwendung die Steuerung der Aufträge durch Prozessbeschränkung für die einzelnen TAC-Klassen gesteuert wird (Generierung ohne TAC-PRIORITIES-Anweisung), auch Folgendes beachten:
Existiert eine Asynchron-TAC-Klasse, für die der aktuell eingestellte Wert von TASKS-FREE größer als oder gleich ASYNTASKS ist, dann wird diese TAC-Klasse gesperrt, d.h. es werden keine Aufträge für diese TAC-Klasse mehr bearbeitet. TASKS-FREE ist in diesem Fall die Anzahl der Prozesse, die mindestens für die Bearbeitung von Aufträgen an andere Asynchron-TAC-Klassen freigehalten werden soll.
Zur Kontrolle sollten Sie nach dem Herabsetzen von ASYNTASKS Informationen über die TAC-Klassen anfordern.
Analoges gilt für die Maximalzahl der Prozesse, in denen gleichzeitig Teilprogramme mit blockierende Aufrufen ablaufen dürfen (TASKS-IN-PGWT). Beachten Sie jedoch, dass Sie - im Gegensatz zu ASYNTASKS - diese Anzahl nicht auf 0 setzen können, wenn derartige Prozesse generiert sind.
 | KDCINF SYSPARM: |
 | KC_GET_OBJECT mit obj_type=KC_TASKS_PAR: |
In Anwendungen ohne TAC-PRIORITIES-Anweisung:
Prozesszahlen für die einzelnen TAC-Klassen ändern
Ist Ihre Anwendung mit TAC-Klassen ohne die Prioritätensteuerung generiert, dann können Sie die Anzahl der Prozesse, die maximal Aufträge einer TAC-Klasse bearbeiten, für jede TAC-Klasse gesondert festlegen und nach Bedarf ändern.
Beim Eintragen der Transaktionscodes geben Sie an, zu welcher TAC-Klasse ein Transaktionscode gehören soll. Sie können also die Transaktionscodes, die zu langlaufenden Teilprogrammen gehören, in einer oder mehreren TAC-Klassen zusammenfassen. Den Anteil der Prozesse der Anwendung, der gleichzeitig Aufträge für diese TAC-Klassen bearbeiten darf, können Sie dann je nach Auslastung der Anwendung einstellen. Bei Dialog-TAC-Klassen muss mindestens ein Prozess Aufträge der TAC-Klasse bearbeiten dürfen. Bei Asynchron-TAC-Klassen kann die Zahl auf 0 herabgesetzt werden.
Insbesondere sollten Sie die Dialog-TACs der Teilprogramme, die blockierende Aufrufe enthalten (z.B. KDCS-Aufruf PGWT, oder XATMI-Aufruf tpcall), in eine TAC-Klasse (mit PGWT=YES) zusammenfassen.
Nach einem blockierenden Aufruf wartet das Teilprogramm, bis die für den weiteren Programmablauf benötigten Daten eingetroffen sind. Für diese Zeit belegt das Teilprogramm bzw. der zugehörige Transaktionscode einen Prozess der Anwendung exklusiv.
Laufen mehrere derartige Teilprogramme gleichzeitig, dann kann es passieren, dass andere Aufträge in der Warteschlange stehen bleiben, weil keine Prozesse für ihre Bearbeitung verfügbar sind. Die Performance der Anwendung wird dadurch stark beeinträchtigt. Die Wartezeit nach einem blockierenden Aufruf kann auch mit dem Timer PGWTTIME begrenzt werden (siehe unten).
 | KDCINF TACCLASS: |
 | KC_GET_OBJECT mit obj_type=KC_TACCLASS: |
Einstellung der Timer ändern
Um zu verhindern, dass Prozesse der Anwendung unnötig lange belegt sind, weil sie auf das Freiwerden von Betriebsmitteln oder auf den Aufbau von Verbindungen und Sessions warten, sind Timer definiert. Die Timer überwachen diese Wartezeiten und setzen die wartende Transaktion nach Ablauf der angegebenen Zeit zurück. Die Timer werden bei der KDCDEF-Generierung festgelegt und können im laufenden Betrieb angepasst werden.
In openUTM sind u.a. Timer für folgende Wartezeiten definiert:
Wartezeit nach einem blockierenden Aufruf (pgwttime)
Der Timer überwacht die Wartezeit, die ein Teilprogramm nach dem Absetzen eines blockierenden Aufrufs maximal auf die Rückkehr ins Teilprogramm wartet.Zeit, die innerhalb einer Transaktion maximal auf die Antwort von einem Dialog-Partner gewartet wird
(termwait...).Zeit, die ein Betriebsmittel maximal von einer Transaktion belegt werden darf, und Zeit, die ein Teilprogramm maximal auf das Freiwerden von Betriebsmitteln wartet (reswait...).
Mit den Informationsfunktionen (Parametertyp STATISTICS/KC_CURR_PAR) können Sie z.B. ermitteln, wie oft Teilprogramme auf gesperrte Betriebsmittel warten mussten (relative Angabe).
Zeit, die maximal auf die Belegung einer Session/Association zur Partner-Anwendung gewartet wird.
Die Timer sind nur als "Notbremse" für unvorhergesehene Situationen gedacht. Stellen Sie die Timer-Werte daher so ein, dass die Timer beim normalen Ablauf der Anwendung nicht ablaufen. Nur Ausnahmesituationen, wie z.B. ein Programmfehler oder eine ausbleibende Antwort von einer Partner-Anwendung, sollten zu einem Timeout führen.
Sind die Timer pgwttime oder reswait zu groß eingestellt, dann können die einzelnen Prozesse der Anwendung gerade in Engpass-Situationen zu lange von Teilprogrammen belegt sein, die entweder Betriebsmittel zu lange sperren (Langläufer) oder zu lange auf das Freiwerden benötigter Betriebsmittel warten. Sind die Timer zu klein eingestellt, wird die Performance durch häufiges Rücksetzen von Transaktionen belastet.
 | KDCINF SYSPARM oder STATISTICS: KDCAPPL: Timer-Einstellung ändern |
 | KC_GET_OBJECT mit obj_type=KC_TIMER_PAR / KC_CURR_PAR: |
Die Anzahl der angemeldeten Benutzer/Clients begrenzen
Sie können im laufenden Betrieb die Anzahl der Benutzer/Clients beeinflussen, die sich gleichzeitig an die Anwendung anschließen und Services von der Anwendung anfordern können. Dazu stehen Ihnen folgende Möglichkeiten zur Verfügung:
Sie können die Gesamtzahl der Benutzer/Clients, die gleichzeitig bei der Anwendung angemeldet sein können, begrenzen.
Sie können die Anzahl der Clients, die sich gleichzeitig über die einzelnen LTERM-Pools anschließen können, beschränken. Dazu sperren Sie einen Teil der LTERM-Partner des Pools.
Sie können einzelne Clients/LTERM-Partner/Benutzer sperren.
Sie können LTERM-Pools vollständig sperren. Über einen gesperrten LTERM-Pool kann sich kein Benutzer/Client mehr an die Anwendung anschließen.
Nur auf BS2000-Systemen: Sie erlauben nur eine geringe Anzahl paralleler Sessions zu einem Multiplexanschluss.
 | KDCAPPL MAX-CONN-USERS: Gesamtzahl der Benutzer/Clients |
 | KC_MODIFY_OBJECT |
Services sperren
Sie können z.B. langlaufende Services zeitweise sperren, indem Sie den zugehörigen Transaktionscode sperren (Status OFF). Aufträge für gesperrte Transaktionscodes werden nicht mehr angenommen. Bei gesperrten Asynchron-TACs werden keine Aufträge mehr in die Message Queue geschrieben.
Sie können einen Transaktionscode entweder nur in seiner Eigenschaft als Vorgangs-TAC sperren oder Sie können ihn als Vorgangs- und als Folge-TAC sperren (vollständiges Sperren: Status HALT).
Asynchron-Services können Sie auch mit dem Status KEEP sperren. KEEP bedeutet, dass für den Asynchron-TAC zwar Aufträge entgegengenommen, aber noch nicht bearbeitet werden. Die Bearbeitung der Aufträge kann dann zu einem Zeitpunkt erfolgen, zu dem die Anwendung weniger ausgelastet ist, z.B. nachts.
| KDCTAC |
| KC_MODIFY_OBJECT obj_type =KC_TAC |
Engpässe auf Verbindungen zu Partner-Anwendungen verhindern bzw. beheben
Kommt es bei der Kommunikation mit LU6.1- oder OSI TP-Partner-Anwendungen zu Engpässen, können Sie folgende Aktionen durchführen:
Weitere Transportverbindungen zu einer LU6.1-Partner-Anwendung aufbauen. Voraussetzung ist, dass Sie für die Kommunikation zu der Partner-Anwendung mehrere parallele Verbindungen erzeugt oder generiert haben und dass noch nicht alle erzeugten oder generierten Verbindungen aufgebaut sind.
Die Anzahl der parallelen logischen Verbindungen zu einer OSI TP-Partner-Anwendung erhöhen. Die maximal mögliche Anzahl der parallelen Verbindungen wird bei der Generierung in der OSI-LPAP-Anweisung festgelegt.
Den Timer (Accesswait) für die Zeit anpassen, die nach dem Anfordern eines fernen Services auf das Freiwerden bzw. den Aufbau einer Session oder Association zur Partner-Anwendung gewartet wird. Diesen Timer können Sie LTAC-spezifisch einstellen. Wird der Timer für einen Asynchron-LTAC auf 0 gesetzt, dann werden Asynchron-Aufträge für diesen LTAC auch nicht in die lokale Message Queue der Partner-Anwendung eingereiht.
Den Timer (Replywait) anpassen, der das Warten auf die Antwort von der Partner-Anwendung überwacht. Dieser Timer wird ebenfalls LTAC-spezifisch eingestellt.
Die Einstellung des Leerlauf-Timers anpassen (Idletime). Dieser Timer gibt die Zeit an, die sich eine Session oder Association ungenutzt bleiben darf, bevor openUTM die Verbindung zur Partner-Anwendung abbaut. Ist der Timer zu groß eingestellt, werden unnötig Ressourcen an Verbindungen gebunden, die nicht benötigt werden. Ist der Timer zu klein eingestellt, dann werden zu viele Ressourcen verbraucht, um die Verbindung immer wieder aufzubauen. Der Timer wird Partner-spezifisch eingestellt.
 | KDCLPAP / KDCLSES: Verbindungen aufbauen, Idletime anpassen |
 | KC_CREATE_OBJECT obj_type=KC_CON/KC_LSES: |
 | KC_MODIFY_OBJECT obj_type=KC_LPAP/KC_OSI_LPAP/KC_LSES: |
Hinweis für Unix-, Linux- und Windows-Systeme:
Werden in Ihrer Anwendung eine sehr große Anzahl von Verbindungen über denselben BCAMAPPL-Namen oder Zugriffspunkt Ihrer Anwendung abgewickelt, dann kann es zu Engpässen kommen, da Prozesse dann an Systemgrenzen stoßen können (z.B. maximale Anzahl der Filedeskriptoren). Bei der nächsten KDCDEF-Generierung sollten Sie dann mehr BCAMAPPL-Namen und Zugriffspunkte generieren.
Datenkomprimierung ein- oder ausschalten
Falls häufig GSSBs, LSSBs, ULS, TLS oder KB-Programmbereiche in einer Länge größer einer UTM-Seite gelesen oder geschrieben werden, sollten Sie prüfen, ob das Einschalten der Datenkomprimierung die Performance der UTM-Anwendung verbessert.
Ob sich die Datenkomprimierung lohnt, können Sie bei eingeschalteter Datenkomprimierung wie folgt prüfen:
| KDCINF STAT, Feld AVG COMPRESS PAGES SAVED |
| KC_GET_OBJECT mit obj_type =KC_CURR_PAR, Feld avg_saved_pgs_by_compr |
