Lade...
 

Performance (Infrastruktur)

Performance Infrastruktur

Wenn Anwendungen mit InstantView® entwickelt und eingesetzt werden sollen, muss darauf geachtet werden, dass die Performance von den Anwendern akzeptiert wird. Da die CyberEnterprise®-Architektur aus mehreren Schichten besteht können verschiedene Engpässe auftreten:

  • InstantView®-Code (siehe auch hier)
  • Datenbank
  • Netzwerk
  • angebundene Tools (z.B. MS-Office)

Der reine InstantView®-Code wird in der Regel sehr schnell abgearbeitet. Trotzdem sollte darauf geachtet werden, dass keine unnötigen Schleifen, Abfragen, o.ä. durchgeführt werden. Da der InstantView®-Code auch den Zugriff auf die Datenbank regelt, ist vor allem darauf zu achten, dass keine langen offenen Transaktionen bestehen, da sonst locking-Konflikte auftreten können. Da die ClassiX®-Objekte sehr stark untereinander vernetzt sind, können ein paar einfache Anweisung dafür sorgen, dass eine große Menge von Objekten gelockt und daher für andere nicht mehr zugreifbar sind.

Die Datenbank selbst ist in der Regel ebenfalls ausreichend schnell. Probleme können jedoch auftreten, wenn sehr aufwendige Abfragen ausgeführt werden, die nicht durch einen Index beschleunigt werden. Ein weiterer Engpass kann die Zusammenarbeit zwischen ObjectStore-Server und dem Cache-Manager auf Client-Seite sein, wenn viele unterschiedliche Objekte angefasst werden. In diesem Fall werden die Seiten, auf denen die Objekte liegen und die wahrscheinlich  nicht im Client-Cache vorgehalten werden, über das Netzwerk auf den Client kopiert.

Aus den oben genannten Gründen gibt es zwei Möglichkeiten, die Performance zu erhöhen. Einerseits sollte ein maximal schnelles Netzwerk und viel Arbeitsspeicher auf den Clients eingesetzt werden um die Transferrate und den Clientcache zu maximieren. Zum anderen sollten die Objekt so in der Datenbank platziert werden, dass einerseits die Objekte die häufig zusammen gebraucht werden, nahe beieinander liegen (auf einer Page), so dass sie in einem Rutsch übertragen werden. Andererseits sollten die Objekte so verteilt werden, dass die in einer Transaktion nicht benötigten Objekte auf anderen Pages liegen, damit sie nicht mitgelockt werden.

 

Ressourcenmanagement

Prozess CPU Auslastung Festplatten Auslastung Netzwerk Auslastung Speicher Auslastung
Server Nicht intensiv. Intensiv. Intensiv. Nicht intensiv.
Geringe Nutzung für Kommunikation mit Client.
Client Kann intensiv sein;
abhängig von der Anwendung
ObjectStore greift nicht auf die lokale Festplatte zu.
Die Anwendung selbst hat aber die Möglichkeit.
Kann intensiv sein. Kann sehr intensiv sein.
Mapping vieler Daten in den virtuellen Speicher.
Cache-Manager Nicht intensiv. Nicht intensiv. Nicht intensiv.
Sendet und empfängt kurze Nachrichten.
Nicht intensiv.

 

Zusammenfassend kommt es also - neben generell schnellen Prozessoren - auf viel Arbeitsspeicher auf Seite des Client, schnelle Festplatten auf Seite des Servers und einer schnellen Netzwerkverbindung zwischen Client und Server an. Die Übertragung der Daten vom Server zum Client kann mittels der Umgebungsvariablen CX_GLOBAL_FETCH_POLICY gesteuert werden, eine Trennung zwischen rein lesenden und schreibenden - und damit potenziell blockierenden - Zugriffen auf die Datenbank kann durch die Umgebungsvariable CX_DB_DEFAULT_MODE eingestellt werden.

Im folgenden werden Möglichkeiten aufgezeigt, eventuelle Schwachstellen in der Performanz zu identifizieren und zu beheben: