Performance-Aspekte

#### Search Results

Search

# Performance-Aspekte

Dieser Abschnitt enthält allgemeine Ratschläge bei leistungsrelevanten Problemen im Zusammenhang mit dem Buffer Pool und den BP Cache.

Erläuterungen zu den in diesem Abschnitt genannten Statistikelementen finden Sie unter Buffer Pool Load/Locate-Statistiken.

Dieses Kapitel behandelt die folgenden Themen:

- Interne Fast-Locate-Tabelle

- Suche in Steplibs

- Wiederverwendung und Beibehaltung von Objekten

- Lokaler oder globaler Buffer Pool?

#### Verwandtes Thema:

- Performance-Hinweise

## Interne Fast-Locate-Tabelle

Wenn innerhalb einer Natural-Sitzung ein Natural-Objekt erstmalig referenziert wird, erstellt der Buffer Pool Manager einen Verzeichniseintrag für dieses Objekt. Ein Verzeichniseintrag dient zur Identifizierung eines Objekts und enthält Informationen wie den Namen des Objekts, die Library, in der es sich befindet (Name, Datenbankkennung und Dateinummer) und die Adresse des Objekts (Position) im Buffer Pool.

Das Natural-Laufzeitsystem speichert die Namen der Objekte, die kürzlich ausgeführt wurden, die Libraries (Name, Datenbankkennung und Dateinummer), in denen sie sich befinden, und (zur Schnellsuche) die Adressen der entsprechenden Buffer Pool-Verzeichniseinträge in der internen Fast-Locate-Tabelle für die Dauer einer Natural-Sitzung.

Wenn ein Benutzer ein Objekt aufruft, das zuvor in der Natural-Sitzung verwendet wurde, gibt das Natural-Laufzeitsystem die Informationen aus der internen Fast-Locate-Tabelle an den Buffer Pool Manager weiter, der dann die normale Lokalisierungsprozedur (Normal Locate) umgehen und einen zeitsparenden Schnellsuche-Aufruf (Fast Locate) durchführen kann (siehe Quick Locate Calls). Dies ist der effizienteste Weg, um ein Objekt zu lokalisieren.

Wenn sich die Position eines Objekts im Buffer Pool geändert hat, plant der Buffer Pool Manager automatisch einen Normal Locate-Aufruf. Die Position ändert sich in der Regel, wenn ein Objekt, das aus dem Buffer Pool gelöscht oder durch ein anderes Objekt überschrieben wurde, erneut in den Buffer Pool geladen wird.

Die interne Schnellsuche-Tabelle enthält maximal 128 Einträge. Die Schnellsuche-Tabelle wird mit dem Systemkommando `LOGON` (Anmelden) zurückgesetzt und muss mit Normal Locate-Aufrufen erneut gefüllt werden. Daher verliert eine Anwendung, die ein `LOGON` durchführt, an Leistung.

Ein hohes Verhältnis von Normal Locate Calls zu Quick Locate Calls deutet auf die Verwendung von `LOGON`-Kommandos in einer Natural-Anwendung hin, da jedes `LOGON` ein Zurücksetzen der internen Fast Locate-Tabelle bewirkt.

- Unerwartete Suchergebnisse bei gesetztem BPSFI-Parameter

### Unerwartete Suchergebnisse bei gesetztem BPSFI-Parameter

Wenn der Profilparameter `BPSFI` (Objektsuche zuerst im Buffer Pool) auf `OFF` gesetzt ist, kann das folgende Szenario zu unerwarteten Ergebnissen führen:

- Die Liste der Steplibs enthält die Libraries S1 und S2, wobei S1 vor S2 durchsucht wird.

- Während der aktuellen Natural-Sitzung wird auf ein Objekt aus S2 zugegriffen.

- Eine andere Natural-Sitzung kopiert eine neue Version dieses Objekts in S1.

Wird dann während der aktuellen Sitzung (ohne neues `LOGON`) erneut auf dieses Objekt zugegriffen, wird die neue Version des Objekts nicht verwendet.

Beachten Sie Folgendes, um solche unerwarteten Suchergebnisse zu vermeiden:

- Setzen Sie ein `LOGON`-Systemkommando ab.

- Da ein LOGON-Kommando in einer Client/Server-Umgebung nicht abgesetzt werden kann, können Sie die Anwendungsprogrammierschnittstelle (API) USR3004N verwenden, um die Fast-Locate-Tabelle zu löschen.

  Weitere Informationen zur Verwendung von APIs finden Sie in der Beschreibung des Dienstprogramms SYSEXT.

- Wenn `BPSFI=ON` gesetzt ist, sollten Objektnamen in allen Libraries, die an Objektsuchoperationen beteiligt sind, immer eindeutig sein. Damit ist auch gewährleistet, dass solche Szenarien nicht auftreten.

## Suche in Steplibs

Die Suche nach einem Natural-Objekt in einer langen Kette von Steplib-Libraries hat einen negativen Einfluss auf die Performance.

Für jede Steplib ruft die Natural-Laufzeit den Buffer Pool Manager auf, bis das gesuchte Objekt gefunden wird. Jeder unnötige Aufruf einer Steplib-Library, die das angeforderte Objekt nicht enthält, kann jedoch normalerweise vermieden werden.

Abhängig von der Einstellung des Profilparameters `BPSFI` (siehe Parameter-Referenz-Dokumentation) können zusätzliche Datenbankaufrufe erforderlich sein.

Eine lange Steplib-Kette zeigt sich durch ein hohes Verhältnis von Normal Locate Calls (einschließlich Steplib-Suchen) zu Normal Locate Calls (ohne Steplib-Suchen), das wie folgt berechnet wird:

Normal Locate Calls: (Normal Locate Calls - STEPLIB Searches)

### Beispiel für eine Steplib-Suche

Beim Durchsuchen der Standard-Steplib-Kette (Library SYSTEM von FUSER, Library SYSTEM von FNAT) führt jeder Versuch, ein Objekt aus SYSTEM (FNAT) zu laden, zu Folgendem:

3 Normal Locate Calls und 2 STEPLIB Searches

Erläuterung:
3 Normal Locate-Aufrufe resultieren aus Suchen in der aktuellen Library, der Library SYSTEM (FUSER) und der Library SYSTEM (FNAT). Es gibt (mindestens) 2 Normal Locate-Aufrufe, die fehlschlagen, da das Objekt weder in der aktuellen Library noch in der Library SYSTEM (FUSER) gespeichert ist. Bei Anwendung der obigen Formel ergibt sich ein Verhältnis von 3:1.

Befindet sich das Objekt in der aktuellen Library, ist das Ergebnis wie folgt:

1 Normal Locate Call und 0 (Null) STEPLIB Searches.

Bei Anwendung der obigen Formel ergibt sich ein Verhältnis von 1:1.

## Wiederverwendung und Beibehaltung von Objekten

Eine Anwendung, die viele Natural-Objekte enthält, wobei jedes Objekt nur selten ausgeführt wird, hat starke Auswirkungen auf die Leistung des Buffer Pool. Keines der Objekte verbleibt lange im Buffer Pool und viele Objekte müssen aus einer Systemdatei geladen werden. Aus Performance-Gründen sollte eine Anwendung Objekte so oft wie möglich wiederverwenden, z. B. indem sie identischen Quellcode, der in mehreren Objekten enthalten ist, in ein einziges Objekt verschiebt.

Sie können die Verwendung von Objekten mit der Funktion List Objects überprüfen (siehe Abschnitt Objekte auflisten). Die Spalte Max enthält z.B. Informationen über die maximale Anzahl von Anwendungen, die ein Objekt ausgeführt haben, und die Spalte TotalUC enthält die Gesamtzahl der Locate-Aufrufe eines Objekts, das in den Buffer Pool geladen wurde.

Objekte können einzeln mit der Funktion List Objects oder durch Angabe in einer Preload-Liste resident gemacht werden (siehe Preload-Liste verwalten).

## Lokaler oder globaler Buffer Pool?

Es gibt keine allgemeinen Empfehlungen, wann ein lokaler oder ein globaler Buffer Pool verwendet werden sollte, da verschiedene Anwendungen unterschiedliche Anforderungen haben. Aufgrund von Erfahrungswerten können wir jedoch allgemeine Ratschläge geben:

- Lokale Buffer Pools verwenden

- Globalen Buffer Pool verwenden

### Lokale Buffer Pools verwenden

Die Performance kann durch die Verwendung mehrerer kleiner lokaler Buffer Pools anstelle eines einzigen globalen Buffer Pools verbessert werden, wenn die lokalen Buffer Pools verschiedenen Anwendungsumgebungen zugewiesen werden können.

In CICS-Umgebungen beispielsweise verbessert sich die Leistung in der Regel durch die Verwendung eines lokalen Buffer Pools für jede AOR (Application Operating Region).

### Globalen Buffer Pool verwenden

Bei verschiedenen Batch-Anwendungen, die auf die gleichen Natural-Objekte verweisen, kann sich die Performance verbessern, wenn diese Anwendungen einen gemeinsamen globalen Buffer Pool anstelle eines lokalen Buffer Pools für jede einzelne Anwendung verwenden. In diesem Fall ist die Wahrscheinlichkeit höher, dass die von jeder Anwendung benötigten Objekte bereits von einer der anderen Anwendungen in den globalen Buffer Pool geladen wurden.

### On this page

- Interne Fast-Locate-Tabelle
- Suche in Steplibs
- Wiederverwendung und Beibehaltung von Objekten
- Lokaler oder globaler Buffer Pool?