Der P-Code-Cache im Detail

Für die Verarbeitung von Prozeduren muss sich der ausführbare Prozedurcode im Hauptspeicher befinden. CONZEPT 16 lädt dabei nur den Code aus der Datenbank, der tatsächlich benötigt wird. Durch dieses Verfahren kann eine Prozedur unabhängig von den verfügbaren Speicherressourcen durchgeführt werden, um das Codemanagement braucht sich der Entwickler nicht zu kümmern. Für bestimmte Anwendungsfälle ist es dennoch hilfreich, die Mechanismen des P-Code-Caches zu kennen.


Generierung von Prozedurcode und Runtime-Daten

Der bei der Übersetzung einer Prozedur entstehende P-Code wird nicht in einem Stück gespeichert, sondern er besteht aus einer Anzahl von 2 KB großen Codeblöcken, die später unabhängig voneinander verwaltet werden können. Zur Ausführung der einzelnen Funktionen sind zusätzliche Metadaten erforderlich, deren Erzeugung ebenfalls bei der Prozedurübersetzung stattfindet, die aber getrennt vom Prozedurcode in der Datenbank abgelegt werden. Zu diesen Metadaten gehören beispielsweise die Namen, Argumenttypen und Startadressen der einzelnen Subfunktionen, Namen und Größen der globalen Datenbereiche sowie Variablen-Informationen für den Debugger.

Laden und Ausführen

Bevor die erste Anweisung einer Prozedur ausgeführt wird, müssen zunächst die Basis-Metadaten für die Subfunktionen geladen werden. Anhand des Namens der Subfunktion wird die Startadresse und somit der benötigte Codeblock der Prozedur ermittelt. Dieser Codeblock wird dann aus der Datenbank in den P-Code-Cache geladen, sofern er sich nicht bereits darin befindet. Anschließend startet die Abarbeitung des P-Codes. Bei jedem Programmsprung aus dem aktuellen Codeblock heraus wird anhand der Zieladresse der benötigte Codeblock ermittelt und dann geladen.

Cache-Management

Für die Codeblöcke aller Prozeduren gibt es einen gemeinsamen Pufferspeicher, dessen Größe unabhängig von der Gesamtmenge des in der Datenbank vorhandenen Prozedurcodes ist. Der Puffer füllt sich automatisch im Verlauf der Prozeduraufrufe. Ist der Puffer komplett gefüllt, wird beim Laden eines weiteren Codeblocks der bisher am längsten nicht verwendete Block aus dem Puffer entfernt. Falls die Puffergröße zu klein gewählt ist, müssen dieselben Codeblöcke innerhalb einer Verarbeitung mehrfach geladen werden, was naturgemäß die Verarbeitungsgeschwindigkeit bremst und den Netzwerk-Traffic erhöht. Die maximale Menge an gepufferten Metadaten ist ab Version 5.7.08 an die Puffergröße gekoppelt. In allen vorherigen Version gibt es eine statische Beschränkung.

Standardgrößen

Je nach Client-Typ ist die Standardgröße unterschiedlich definiert. Die Standardgröße ist davon abhängig, wie viele Instanzen des P-Code-Caches es typischerweise auf einem Rechner gibt und ob auch Prozeduren für die GUI zur Ausführung kommen. Ab Version 5.7.08 gibt es daher drei unterschiedliche Größenvorgaben (die API-DLL verwendet keine Standardgröße):

8 MB (GUI / wenige Instanzen)

– Standard Client
– Advanced Client
– 3.x Client
– Jobs in diesen Clients

2 MB (ohne GUI / viele Instanzen)

– SOA
– Jobs im SOA-Service
– PHP
– Druckprozessor
– Server

256 KB (ohne GUI / kein eigener Adressraum)

– ODBC
– Web-Schnittstelle

Änderung der Puffergröße

Mit zwei neuen Eigenschaften des _Sys-Objekts kann die aktuelle Größe des P-Code-Caches abgefragt und geändert werden (_Sys->spProcCacheLimitKB), außerdem lässt sich die aktuelle Pufferbelegung ermitteln (_Sys->spProcCacheKB). Im laufenden Betrieb kann sowohl eine Vergrößerung als auch eine Verkleinerung des Puffers erfolgen. Die Maximalgröße beträgt 64 MB, das Minimum liegt bei 256 KB.

mehr Puffer

Eine Vergrößerung des Puffers ist sinnvoll, wenn innerhalb einer Anwendungskomponente deutlich mehr Code geladen wird, als in den Standardpuffer hineinpasst. Zur Ermittlung dieser Menge wird beispielsweise die Applikation gestartet, der P-Code-Cache auf Maximalgröße _Sys->spProcCacheLimitKB # (1024 * 64) gestellt und die wichtigsten Funktionen einer Komponente ausgeführt. Abschließend wird die aktuelle Größe abgefragt. Für die nächste Anwendungskomponente muss der Client dann neu gestartet werden, da ansonsten der bisher geladene Prozedurcode natürlich im Puffer verbleibt. Anhand der ermittelten Werte kann dann entschieden werden, ob für die Applikation ein größerer Maximalwert sinnvoll ist. Dieser sollte dann innerhalb der Initialisierungsprozedur der Anwendung gesetzt werden. Alternativ ist das Limit beim SOA-Service auch in der Konfigurationsdatei des Tasks einstellbar.

weniger Puffer

Eine Verkleinerung des Puffers ist nur in den Fällen notwendig, in denen sehr viele Instanzen gleichzeitig laufen und wenig Speicher verfügbar ist, beispielsweise bei zahlreichen Datenbankbenutzern im SOA-Socket-Task oder vielen Jobs im Standard- oder Advanced-Client.

Klicken Sie hier, um die Nutzungsbedingungen für unseren Blog zu lesen.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Leave the field below empty!

Wünsche, Fragen oder Feedback sind willkommen:

Nutzungsbedingungen der Kommentarfunktion im Blog

1. Allgemeines

Vectorsoft AG („Anbieter“) stellt für Internetnutzer („Nutzer“) auf der Website
vectorsoft.de einen öffentlichen Blog bereit. Der öffentliche Blog dient dem
Informations- und Gedankenaustausch. Die Nutzer, welche sich mit Beiträgen und
Kommentaren beteiligen, verpflichten sich dazu, die Blog-Nutzungsbedingungen
einzuhalten und tragen die Verantwortung für die Richtigkeit und Angemessenheit
sowie Freiheit von Rechtsverletzungen ihrer Beiträge. Mit Nutzung der
Kommentarfunktion in unserem Blog akzeptieren Sie diese Nutzungsbedingungen.

2. Netiquette

Wir bitten Sie von persönlichen Angriffen und Provokationen aufgrund anderer
Meinungen abzusehen. Bitte argumentieren Sie sachlich und bewegen Sie sich auf
der Basis einer konstruktiven Diskussionskultur. Ihr Kommentar sollte stets im
Zusammenhang mit dem jeweiligen Thema sein, um Ausschweifungen in andere
Themenbereiche zu vermeiden. Das mehrmalige Posten desselben Kommentars
oder mehrerer ähnlicher Kommentare ist nicht erlaubt.

3. Verbot rechtswidriger Inhalte

Mit Absenden Ihres Kommentars bestätigen Sie, dass Sie keine Urheberrechte oder andere Rechte Dritter verletzen. Volksverhetzende, rassistische Äußerungen, Anleitungen zu Straftaten und deren Verherrlichung, Gewaltdarstellungen, pornografische Inhalte und Äußerungen, die Persönlichkeitsrechte verletzen sind untersagt.

4. Keine Werbung

Die Nutzung der Kommentarfunktion ist für kommerzielle oder parteipolitische
Zwecke nicht erlaubt. Werbliche Beiträge aller Art werden von uns umgehend
gelöscht.

5. Angaben zum Namen

Bei der Eingabe Ihres Namens achten Sie auf die zuvor genannten Grundsätze.

6. Quellenangaben

Bitte geben Sie bei der beabsichtigten Veröffentlichung von Zitaten oder Beiträgen
Dritter die jeweiligen Quellen an und erläutern dessen Bezug zum Blogbeitrag.

7. Verstoß gegen die Nutzungsbedingungen

Beiträge, die gegen diese Richtlinie verstoßen werden umgehend gelöscht. Sollten
Sie selbst Verstöße bemerken, so senden Sie uns bitte den Link des betreffenden
Kommentars per E-Mail an . Wir weisen ausdrücklich daraufhin, dass wir einzelne Nutzer bei wiederholten oder schweren Verstößen gegen diese
Nutzungsbedingungen ausschließen werden.

Stand: Sept. 2024

Deine Trial Version - jetzt anfordern!

Teste yeet - unverbindlich und kostenfrei

IHRE EVALUIERUNGSLIZENZ - JETZT ANFORDERN!

TESTEN SIE DIE CONZEPT 16 VOLLVERSION - UNVERBINDLICH und KOSTENFREI

Melden Sie sich bei unserem Newsletter an

Anrede*
     
Zustimmung zur Datenverarbeitung gem. DSGVO*



WordPress Cookie-Hinweis von Real Cookie Banner