Performance im Netz

Erstellt: 29.11.2010, Änderung:
Abschnitt Aktualisierte Index Statistiken hinzugefügt.
Mehr ansehen

Wenn Sie annehmen, dass auftretende Performance-Probleme nicht von Ihrer Vertec-Konfiguration verursacht werden - siehe dazu den Artikel Performance - könnte die Ursache zum Beispiel auch ein Netzwerkproblem sein. Nachfolgende Angaben sollen Ihnen helfen, dem Problem auf die Spur zu kommen.

Einflussfaktoren für Netzwerk- und Serverperformance sind:

  • Serverauslastung
  • Netzwerkbandbreite
  • Latenz

Serverauslastung

Entspricht Ihr Server den Anforderungen?

Verwenden Sie eine ältere Firebird Version? In diesem Fall könnte es helfen, auf Firebird 3.0 umzustellen, da Firebird 3.0 als erste Firebird Version multiprozessorfähig (SMP) ist.

Die Performance auf dem Server kann auch durch andere Services, Firewalls, Virenscanner etc. beinflusst werden. Netzwerkprobleme sind in der Regel komplex. Um solchen Schwierigkeiten auf den Grund gehen zu können, braucht es einen Netzwerkspezialisten, der mit Tools wie z.B. dem Netzwerkanalyseprogramm WireShark herausfinden kann, wodurch die Probleme verursacht werden.

Die Erfahrung zeigt, dass Vertec auf einem Small Business Server nicht performant genug läuft. Das Problem ist dabei nicht der Small Business Server, sondern der (damit mitgelieferte) Exchange-Server, welcher den Speicherplatz fast vollständig für sich beansprucht und die CPU auslastet. Dabei spielt die Grösse des Speicherplatzes keine Rolle. Vertec sollte deshalb nicht auf dem gleichen Server wie ein Exchange-Server installiert werden.

Wahl des Datenbankservers

  • Bei Installationen bis ca. 50-100 Usern ist Firebird 3.0 die beste Wahl, da sehr performant und in der Administration sehr einfach, z.B. bezüglich Backup. Ab Version 6.1 wird Vertec standardmässig mit Firebird 3.0 ausgeliefert.
  • Ab 100 Usern oder bei besonderen Anforderungen bezüglich der Performance kann der Einsatz eines Microsoft SQL-Server in Erwägung gezogen werden. Dieser skaliert bei sehr vielen gleichzeitigen Usern und Transaktionen sehr gut.

Dedicated vs. Shared Ressourcen

Eine höhere Anzahl CPU's bringt bei grossen Installationen bereits eine grosse Performance-Verbesserung. Eine weitere Verbesserung kann durch das fixe Zuweisen von Ressourcen (dedicated) erzielt werden. Zum Vergleich folgende Tabelle mit Performance-Werten:

4 CPU, shared Ressourcen8 CPU, shared Ressourcen8 CPU, dedicated Ressourcen
Dauer der Berechnung100%56%48%
  • Bei vielen Usern und grossen Datenbanken sind die Ressourcen des Microsoft SQL-Servers entscheidend! Läuft dieser nicht optimal, kommen auch Optimierungen in Vertec an ihre Grenzen.
  • Eine VM mit shared Ressourcen ist einer VM mit dedicated Ressourcen performancemässig unterlegen. Für ein Produktivsystem wie Vertec sollte die VM bei vielen Usern und grossen Datenbanken mit fix zugewiesenen Ressourcen arbeiten.

Aktualisierte Index Statistiken

Die Datenbank Server brauchen Index Statistiken, um herauszufinden, welcher Index in welcher Reihenfolge verwendet werden soll. Zum Beispiel gibt es für ein "Mann/Frau" Feld genau 2 Möglichkeiten, bei einem Index auf einer Postleitzahl sehr viel mehr. Mit der Index Statistik kann ein Query Analyzer eruieren, welchen Index er zuerst benutzen soll und welchen als zweites etc. Das ist performancerelevant.

Nun werden die Index Statistiken nicht einfach so neu berechnet. Bei Firebird geschieht das zum Beispiel bei einem Restore. Der Vertec Datenbank-Konvert jedoch füllt die Daten erst nach einem Restore ein; die Index Statistiken fehlen so.

Das bedeutet, dass die Indizes zwar benutzt werden, allenfalls aber nicht in der richtigen Reihenfolge.

Firebird

Ab Vertec 6.3 wird die Index Statistik Berechnung nach dem Einfüllen der Daten automatisch angestossen.

In Versionen vor 6.3 können die Index Statistiken auch manuell erstellt werden mit folgendem SQL-Skript:

execute blockasdeclare variable ix varchar(31);begin  for select rdb$indices.rdb$index_name  from rdb$indices  into ix  do  execute statement 'SET STATISTICS INDEX '||ix ;end

Microsoft SQL-Server

Ab Vertec 6.3 wird die Index Statistik Berechnung nach dem Einfüllen der Daten automatisch angestossen. Bei MS SQL-Server funktioniert das aktuell jedoch nur, wenn der VertecUser auch DBO ist. In allen anderen Fällen oder vor Vertec 6.3 muss die Berechnung von Hand angestossen werden. Informationen dazu finden Sie im Artikel über den Konvert mit MS SQL-Server.

Clients

Bei der Verarbeitung der Businesslogik macht Vertec viele Einzelzugriffe. Bei Desktop Clients (Desktop App und Classic App) läuft die Businesslogik lokal, bei Cloud Clients (Cloud App und Web App) nicht. Je nachdem, wo diese Logik abläuft, sind unterschiedliche Kriterien performance-entscheidend:

Desktop Clients

Eine hohe Netzwerkbandbreite wirkt sich sicher positiv auf die Performance aus, wesentlicher für den schnellen Betrieb von Vertec ist jedoch die Latenz des Netzwerks.

Vertec macht bei der Verarbeitung der Business-Logik relativ viele Einzelzugriffe über das Netzwerk und reagiert deshalb empfindlich auf lange Antwortzeiten (Latenz). Vertec läuft in diesen Fällen langsamer, da der Client bei jedem einzelnen Paket auf Antwort wartet. Dies kann auch bei ansonsten sehr schnellen Leitungen (hohe Netzwerk-Bandbreite) problematisch sein. Wenn die Pakete unterwegs bei einer Station (z.B. einem fehlkonfigurierten Switch) aufgehalten werden, nützt es nichts, wenn die Wege dazwischen schnell sind. Ein Indikator für hohe Latenz ist, wenn die Antwortzeiten bei Pings durchschnittlich grösser als 1 Millisekunde sind.

Vertec in WAN Systemen

Greift der Client via VPN auf den Server zu (WAN), ist die Latenz entscheidend. Vertec lässt sich via VPN betreiben, Voraussetzung ist dafür der Einsatz von MS SQL-Server oder der Einsatz von Firebird 3.0, mit welchem sich ebenfalls ansprechende Resultate erzielen lassen. Der Einsatz von Vertec im WAN mit Firebird Versionen unter 2.5 ist nicht möglich, da diese Version noch nicht für hohe Latenzzeiten optimiert ist.

Hier empfiehlt sich der Einsatz von Cloud Clients, da diese im WAN performanter sind; auf Windows zum Beispiel die Cloud App.

Cloud Clients

Hier übernimmt der Cloud Server die "lokale" Rolle. Deshalb ist es für die Performance am Besten, wenn der Cloud Server so nahe wie möglich am Datenbankserver ist, mit tiefer Latenz und hoher Bandbreite.

Den Clients werden über das Netz nur die Resultate geschickt, was wenig Zeit braucht, deshalb ist die Bandbreite von den Clients zum Server unerheblich. Eine tiefe Latenz ist für Cloud Clients von Vorteil, da alle Oberflächen-Manipulationen an den Server gemeldet werden.

Auch bei den Cloud Clients gelten die normalen Performance-Kriterien, da die Verarbeitung in Vertec ja trotzdem erfolgt. Einzig die gesamthafte Übertragung zu den Clients fällt weg, was enorme Vorteile zum Beispiel beim Einsatz von Vertec via VPN bringt.