Performance im Netz

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

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.

• 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.

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:

• 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.

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.

Sind Index Statistiken nicht aktuell, kann es passieren, dass die Indizes zwar benutzt werden, aber nicht in der richtigen Reihenfolge.

Detaillierte Informationen zu diesem Thema finden Sie im Artikel Datenbank Performance und Index Statistiken.

Bei der Verarbeitung der Businesslogik macht Vertec viele Einzelzugriffe. Bei der Desktop 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:

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.

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.

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.