Einleitung
Der folgende Artikel soll Ihnen helfen, die Systemeinstellungen zu überprüfen, ggf. zu korrigieren oder zu ändern und somit eine erste eigene Problemanalyse/-behebung durchführen zu können.
Insbesondere bei der unten aufgezählten IT-Infrastruktur kann es durch Konfigurationsänderungen zu einem erheblichen Performance-Gewinn bei der Arbeit mit dem combit Relationship Manager (cRM) kommen.
- Windows Client- und Server-Betriebssysteme
- Firewall (client-/serverseitig)
- Anti-Virenscanner (client-/serverseitig)
Wichtig: Bitte beachten Sie, dass oftmals ein Neustart des Clients bzw. des Servers notwendig ist, damit die Änderungen angewendet werden können.
Client- und serverseitige Einstellungen
Netzwerk-Anbieterreihenfolge
In der Auswertungsreihenfolge der Netzwerkanbieter der Netzwerkkarte sollte das „Microsoft Windows-Netzwerk“ als Erstes ausgewertet werden. Den Einstellungsdialog erreicht man über:
Netzwerk- und Freigabecenter > Adaptereinstellungen ändern > Erweitert (falls Menüleiste ausgeblendet, „Alt“-Taste betätigen) > Erweiterte Einstellungen > Anbieterreihenfolge
Deaktivieren von IPv6
Bei der Kommunikation zwischen „älteren“ Windows-Servern und „neueren“ Windows-Clients kann es zu Engpässen bzgl. des verwendeten IP-Protokolls kommen. Das IPv6-Protokoll sollte daher deaktiviert werden. Dies muss in den Einstellungen der LAN-Verbindungen erfolgen:
Datenbankverbindung über die Server-IP-Adresse
Bei dieser Systemkonstellation kann es auch zu Problemen bei der DNS-Auflösung kommen. Folglich kann die Datenbankanbindung im cRM über den Servernamen zu Problemen führen. Abhilfe schafft hier die Verwendung der Server-IP-Adresse anstatt des Servernamens. Diese Änderung kann im Datenbankverbindungsdialog des cRM vorgenommen werden, welche über die Projekt-Menüleiste und die Menüpunkte „Konfigurieren > Datenbank > Datenbankverbindung“ erreichbar ist.
Wenn Sie die IP-Adresse nicht verwenden können oder möchten, so empfehlen wir allerdings unbedingt, auf die Nutzung des NetBIOS-Namens zu verzichten und stattdessen den sog. fully qualified domain name des Servers anzugeben. Denn wenn als Datenbankserver-Name der NetBIOS-Computername des Servers benutzt wird, kann dies die Performance des cRM deutlich beeinträchtigen, falls der Hostanteil des eigentlichen fully qualified Servernamens länger als 15 Zeichen ist. Verwenden Sie also beispielsweise langerRechnername.example.de anstatt langerRechnername als Datenbankserver-Namen. Der NetBios-Name ist auf 15 Bytes beschränkt (was üblicherweise 15 Zeichen entspricht) und wird unter Umständen entsprechend gekürzt bzw. abgeschnitten, was wiederum zu Konflikten bei der NetBIOS-Namensauflösung führen kann. Weitere Informationen hierzu finden Sie im Microsoft-KB-Artikel Konfigurationsoptionen für den Serverarbeitsspeicher.
TCP/IP vs. Named Pipes
Die Verbindung bzw. die Kommunikation der Clients mit dem SQL-Server erfolgt über ein einziges Protokoll. Hierbei kann es ebenfalls zu Verzögerungen kommen, wenn der Server einem Protokoll lauscht, welches der Client jedoch erst in Erfahrung bringen muss. Hier lässt sich ebenfalls die Auswertungsreihenfolge ändern und das verwendete Protokoll somit priorisieren. In diesen Dialog gelangen Sie folgendermaßen:
Client (ohne SQL-Tools)
Start > Alle Programme > Verwaltung > Computerverwaltung > Dienste und Anwendungen > SQL Server-Konfigurations-Manager > SQL Native Client (10.0)-Konfiguration > Clientprotokolle
Server/Client mit SQL-Tools
Start > Alle Programme > MS SQL Server 2008 (R2) > Konfigurationstools > SQL-Server-Konfigurations-Manager > SQL Native Client (10.0)-Konfiguration > Clientprotokolle
Zu beachten sind die folgenden Hinweise von Microsoft:
TCP/IP
TCP/IP ist ein Protokoll, das im Internet häufig verwendet wird. Es kommuniziert über untereinander verbundene Computernetzwerke mit unterschiedlichen Hardwarearchitekturen und verschiedenen Betriebssystemen. TCP/IP schließt Standards zum Weiterleiten von Netzwerkverkehr ein und bietet erweiterte Sicherheitsfunktionen. Es ist das heute in der Geschäftswelt am häufigsten verwendete Protokoll. Das Konfigurieren des Computers für die Verwendung von TCP/IP kann ein komplexer Vorgang sein, allerdings sind die meisten Netzwerkcomputer bereits ordnungsgemäß konfiguriert. Weitere Informationen zum Konfigurieren der TCP/IP-Einstellungen, die nicht im SQL Server-Konfigurations-Manager verfügbar sind, finden Sie in der Microsoft Windows-Dokumentation.
Named Pipes
Named Pipes ist ein Protokoll, das für lokale Netzwerke entwickelt wurde. Ein Teil des Arbeitsspeichers wird von einem Vorgang zum Weiterleiten von Informationen an einen anderen Vorgang verwendet, sodass die Ausgabe des einen Vorgangs der Eingabe des anderen entspricht. Der zweite Prozess kann ein lokaler (auf demselben Computer wie der erste) oder ein Remoteprozess (auf einem Computer im Netzwerk) sein.
Named Pipes im Vergleich zu TCP/IP-Sockets
In einer schnellen LAN-Umgebung (Local Area Network) sind TCP/IP-Sockets (Transmission Control Protocol/Internet Protocol) und Named Pipes-Clients hinsichtlich der Leistung vergleichbar. Der Leistungsunterschied zwischen TCP/IP-Sockets und Named Pipes-Clients wird jedoch in langsameren Netzwerken, wie z. B. WANs oder Einwählverbindungen, deutlich. Ursache hierfür sind die Unterschiede in der prozessübergreifenden Kommunikation (Interprocess Communication, IPC) zwischen Peers.
Für Named Pipes ist die Netzwerkkommunikation normalerweise überwiegend interaktiv. Ein Peer sendet keine Daten, bevor ein anderer Peer sie mithilfe eines Lesebefehls anfordert. Zu einem Netzwerklesevorgang gehört normalerweise vor Beginn des Lesens der Daten das kurze Einsehen zahlreicher Named Pipes-Nachrichten. Dies kann in einem langsamen Netzwerk sehr teuer sein und übermäßigen Netzwerkverkehr verursachen, was sich wiederum auf andere Netzwerkclients auswirkt.
Darüber hinaus sollte geklärt werden, ob die Kommunikation über lokale Pipes oder Netzwerkpipes stattfindet. Wenn die Serveranwendung lokal auf dem Computer mit einer Instanz von SQL Server ausgeführt wird, bietet sich das Verwenden des lokalen Named Pipes-Protokolls an. Lokale Named Pipes-Protokolle werden im Kernelmodus ausgeführt und sind sehr schnell.
Für TCP/IP-Sockets sind Datenübertragungen geradliniger und mit weniger Verwaltungsaufwand verbunden. Datenübertragungen können auch von Mechanismen zur TCP/IP-Socketleistungserweiterung, wie beispielsweise Windowing, verzögerten Bestätigungen usw. profitieren. Dies kann in einem langsamen Netzwerk sehr hilfreich sein. Abhängig vom Anwendungstyp können diese Leistungsunterschiede sehr deutlich sein.
TCP/IP-Sockets unterstützen zudem eine Backlogwarteschlange. Dadurch kann im Vergleich zu Named Pipes, die aufgrund von ausgelasteten Pipes zu Fehlern beim Verbindungsversuch mit SQL Server führen können, ein begrenzter Glättungseffekt erreicht werden.
Im Allgemeinen wird TCP/IP in einem langsamen LAN, WAN oder DFÜ-Netzwerk bevorzugt. Wenn die Netzwerkgeschwindigkeit keine Rolle spielt, stellen Named Pipes hingegen häufig die bessere Wahl dar, da sie mehr Funktionalität, größere Benutzerfreundlichkeit und mehr Konfigurationsoptionen bieten.
Aktivieren des Protokolls
Das Protokoll muss sowohl auf dem Client als auch dem Server aktiviert sein. Der Server kann gleichzeitig auf alle aktivierten Protokolle auf Anforderungen lauschen. Clientcomputer können ein Protokoll auswählen oder das Verwenden der Protokolle in der Reihenfolge versuchen, wie sie im SQL Server-Konfigurations-Manager angegeben sind.
TCP Auto-Tuning-Protokoll/RSS
Mit dem Betriebssystem Windows Vista hat Microsoft das sogenannte „TCP Auto-Tuning-Protokoll“ eingeführt. Dieses Protokoll handelt die Fenstergröße für die zwischen Server und Client auszutauschenden Pakete aus, d.h. der Netzwerk-Verkehr wird durch dieses Protokoll ständig überwacht und wirkt sich somit auch auf die Geschwindigkeit z.B. beim Löschen, Kopieren oder Verschieben von Dateien im Netzwerk aus. Dieses Protokoll lässt sich über die Kommandozeile deaktivieren. Diese muss hierfür unbedingt „Als Administrator“ ausgeführt werden. Desweiteren empfiehlt es sich, die RSS-Funktionalität zu deaktivieren (Receive Side Scaling), da diese ebenfalls einen Flaschenhals im Zusammenspiel von Multi-Core-Prozessoren und Single-CPU-Services bildet. Der Befehl zur Deaktivierung lautet wie folgt:
netsh interface tcp set global autotuninglevel=disabled
netsh interface tcp set global rss=disabled
Firewall
Die Microsoft Windows Firewall verhindert nicht autorisierte Zugriffe auf den Computer. Dies kann dazu führen, dass möglicherweise auch Verbindungsversuche von cRM Clients auf die auf diesem Computer laufende Microsoft SQL Server Instanz blockiert werden. Der Effekt kann eine lange Wartezeit oder sogar eine „Timeout“-Fehlermeldung beim Starten des cRM sein.
Microsoft bietet einen Knowledge Base-Artikel mit einem Überblick über die erforderliche Konfiguration der Windows-Firewall für den Zugriff auf den Microsoft SQL Server und fasst Informationen zusammen, die für einen SQL Server-Administrator interessant sind. Hier finden Sie den entsprechenden Artikel in englischer Sprache.
Virenscanner
Insbesondere beim Programmstart aber auch beim Verwenden von Script-Dateien (ggf. hinter Schaltflächen der Eingabemaske verborgen) können aktive Virenscanner zu einem Leistungsverlust führen, da jeder Dateizugriff geprüft wird. Erfahrungen aus der Praxis zeigen, dass es oftmals ausreichend ist, wenn die cRM-Arbeits- und Installationsverzeichnisse von einem permanenten Scan des Virenscanner ausgeschlossen werden. Dies kann sowohl auf dem Client als auch auf dem Server der Fall sein.
Transaktionsprotokoll/Wartungspläne
In einem Transaktionsprotokoll werden die Details aller Änderungen an der SQL Server-Datenbank gespeichert. Das Transaktionsprotokoll der Datenbank sollte nicht unerwartet groß sein bzw. es sollte ein entsprechender Wartungsplan für die Verkleinerung der Datenbank eingerichtet sein (Transaktionsprotokoll wird ebenfalls bei einer entsprechend eingerichteten Datenbanksicherung verkleinert).
Bitte beachten: Für Wartungspläne sind SQL Server Agent und SSIS erforderlich, die von SQL Server Express nicht unterstützt werden. Hier bietet sich ein SQL-Script + sqlcmd.exe und ein geplanter Task an. Die Vorgehensweise ist z.B. hier beschrieben.
Speicherzuordnung SQL Server
Standardmäßig hat der SQL Server eine minimale Serverarbeitsspeicher-Zuordnung von 0 MB und eine maximale Serverarbeitsspeicher-Zuordnung von 2 PB (2147483647 MB). Die momentane Konfiguration können Sie unter „Arbeitsspeicher“ in den Servereigenschaften über das SQL Server Management Studio prüfen. Wenn neben dem SQL Server eventuell andere Anwendungen zusätzlichen Arbeitsspeicher in Anspruch nehmen (zusätzlich zum Betriebssystem), so kann dies ebenfalls zu Performance-Einbußen führen. Die Ermittlung und Anpassung der minimalen sowie maximalen Serverarbeitsspeicher-Zuordnung wird im Microsoft-Artikel Konfigurationsoptionen für den Serverarbeitsspeicher erklärt. Hier finden Sie den entsprechenden Artikel in englischer Sprache. Und der entsprechende Artikel für den SQL Server 2008 R2 ist hier verfügbar.
Treiber
Achten Sie darauf, dass die verwendeten Treiber für die Netzwerk- und Grafikkarte aktuell und für das Betriebssystem freigegeben sind.
Hardware
Achten Sie darauf, dass Server und Client die Mindestvoraussetzungen für den Einsatz des cRM erfüllen. Weitere Informationen dazu befinden sich im cRM-Handbuch.
Überprüfen Sie, ob Ihr Server genügend Arbeitsspeicher und einen ausreichend schnellen Prozessor hat. Der Einsatz von RAID-Systemen bzw. Multiprozessor-Servern kann ebenfalls die Arbeitsgeschwindigkeit erhöhen.
Solution-seitige Einstellungen
Allgemein
Beachten Sie, dass die Aktivierung von Datensatzrechten generell zusätzliche Ressourcen des Datenbankservers beanspruchen wird. Dies könnte sich in einer Verschlechterung der Performance auswirken.
- Versuchen Sie, möglichst einfache Filter zu verwenden.
- Vermeiden Sie Abfragen mit „IS NULL“.
- Vermeiden Sie Filter mit Relationen.
- Wenn die Datensatzrechte von Gruppen abgeleitet sind, vermeiden Sie Gruppenzugehörigkeiten zu mehreren Gruppen mit Datensatzrechten.
- Aktivieren Sie Datensatzrechte nur für die Ansichten, für die sie wirklich notwendig sind.
Indizes
Ein Index enthält Schlüssel, die aus einer oder mehreren Spalten in der Tabelle oder Sicht erstellt werden. Durch das Erstellen gut durchdachter Indizes können Sie die Leistung von Datenbankabfragen und Anwendungen erheblich steigern. Zum Erstellen eines Index klicken Sie im Objekt-Explorer im SQL Server Management Studio (SSMS) mit der rechten Maustaste auf den Ordner „Indizes“ unterhalb einer Tabelle, und wählen Sie dann im Kontextmenü „Neuer Index“ aus. Alternativ erstellen Sie eine Sortierung im cRM.
Verwenden Sie explizite Indizes Ihres Datenbanksystems (nicht zu verwechseln mit den Sortierkriterien im cRM!) für folgende Spalten: die Primärschlüsselspalte, wichtige Spalten nach denen immer wieder sortiert wird (erledigt der cRM nur unter MS SQL Server automatisch!) und in denen häufig gesucht oder gefiltert wird sowie für alle Fremdschlüsselspalten, denn über diese werden Relationen aufgelöst. Es handelt sich dabei um Spalten, die IDs auf fremde Tabellen enthalten, wie bspw. in Verknüpfungsansichten bei n:m Relationen und in 1:n Ansichten.
Sortierungen auf 1:1 verknüpfte Felder sollten nicht angewendet werden, da dies zu einer schlechten Performance führen kann (siehe Absatz Relationen). Dies gilt sowohl für Sortierungen in einer Ansicht selber als auch für ggf. eingestellte Sortierungen in einem sichtbaren Container (Containerfilter).
Primärschlüssel
Das Primärschlüsselfeld der Datenbank sollte als cRM interner Feldtyp „Datensatz-ID“ gekennzeichnet sein. Dies hat zur Folge, dass automatisch ein Index auf dieses Feld angelegt wird. Ansonsten gilt: Verwenden Sie für das Primärschlüsselfeld zur Optimierung der Arbeitsgeschwindigkeit explizite Indizes Ihres Datenbanksystems.
Fremdschlüssel
Auf Fremdschlüsselspalten sollten unbedingt Indizes aufgebaut werden. Über diese Spalten werden Relationen aufgelöst. Es handelt sich hierbei um Spalten, die IDs auf fremde Tabellen enthalten, wie bspw. in Verknüpfungsansichten bei n:m-Relationen und in 1:n Ansichten.
Ein Beispiel hierfür wäre in einer Tabelle „Contacts“ die Spalte „CompanyID“, welche neben dem Primärschlüsselfeld „ContactID“, die Relation zur „Company“ herstellt.
Relationen
Überprüfen Sie alle Relationen auf Ihre tatsächliche Notwendigkeit, da der cRM diese Relationen überall rekursiv auflöst und somit die Arbeitsgeschwindigkeit auch maßgeblich von ihnen abhängt. Unnötige Relationen sollten deshalb entfernt werden, dies gilt bspw. für nicht benötigte 1:1 „Rückrelationen“ von 1:n verknüpften Ansichten. Ein Beispiel hierfür wäre eine Darstellung von Daten von Firmen und Kontakten (Ansprechpartner) innerhalb einer Ansicht.
Eine Auflistung aller Ansichten mit Anzahl der 1:1 Relationen finden Sie im Support-Dialog des cRM. Diesen Dialog können Sie über „? > Über… > Support Informationen“ aufrufen.
Eingabemaske/Übersichtsliste
Versuchen Sie, die Anzahl der Felder pro Datenbank-Tabelle niedrig zu halten. 75 Felder pro Tabelle sollten hier als Maximal-Richtwert verwendet werden.
Jedes auf der aktuellen Eingabemaskenseite platzierte 1:1 Feld verursacht zusätzliche Datenbankabfragen, welche Bandbreite und Performance in Anspruch nehmen. Noch deutlicher wird die Auswirkung bei einer Verwendung als Spalte in Übersichtslisten und Containern, da dann diese Abfragen nicht nur für den aktuellen Datensatz sondern für alle darin dargestellten Datensätze bei jeder Fensteraktualisierung neu durchgeführt werden.
Besonderes Augenmerk sollten Sie auf berechnete Felder und auf 1:1-Relationen auf Datenbanksichten haben, welche Berechnungen (möglichweise sogar über einen Verbindungsserver auf einem anderen Datenbankserver) durchführen. Hier können sich je nach Server-Leistung und wachsender Datenmenge deutliche Auswirkungen auf die Performance einstellen. Insbesondere bei Verbindungsservern kann sich eine Performanceeinbuße allein bereits durch das Anlegen einer derartigen 1:1-Relation bemerkbar machen, also auch wenn deren Feld selbst nicht in Übersichtsliste, Container oder Eingabemaske angezeigt werden.
Dies wirkt sich beim Öffnen der Ansicht aber insbesondere beim Blättern durch die Datensätze sowie beim Umschalten der Eingabemaskenseite aus. Berücksichtigen Sie dies daher, wenn Sie viele solcher 1:1 Felder vor allem aus unterschiedlichen Relationen platzieren möchten.
Blenden Sie in den Listenansichten (Containern) nicht benötigte Spalten komplett aus. In der Übersichtsliste ist dies vor allem für Dateiverweise zu empfehlen, da ansonsten beim Aufbau der Listenansicht jeder einzelne Verweis auf Verfügbarkeit geprüft wird.
Verwenden Sie möglichst kurze Spaltentitel in den Listenansichten (Containern). Bei Relationen verwendet der cRM in der Grundeinstellung lange Namen wie z.B. FirmenID.Firmen.ID.Firma. Diese lassen sich über das Kontextmenü > Konfiguration > Spaltentitel im Nachhinein ändern.
Scripting
In Scripten sollte nicht mit den Methoden „CurrentRecord“ bzw. „CurrentRecordBuffered“ gearbeitet werden. Stattdessen empfiehlt sich die Verwendung von „CurrentRecordSynchronized“. Da bei dieser Methode das komplette Puffern von Feldinhalten entfällt, ist dies die empfohlene Methode, um auf Feldinhalte von Datensätzen zuzugreifen. Desweiteren sollten Scripte nicht anhand der Methode „RecCount“ prüfen, ob ein Filter ein Ergebnis hat, sondern mit dem Rückgabewert des ersten „MoveNext“ nach Filteranwendung arbeiten. Im Anhang der Programmierer-Referenz (SDK-Dokumentation) befindet sich ein Beispiel diesbezüglich.
Häufige Filter
Wenn häufig mit Filtern gearbeitet wird, dann sollten die verwendeten Filter nicht auf Feldern vom cRM internen Feldtyp „Zeichen lang“ (phys.: text, ntext, varchar(max), nvarchar(max)) basieren. Dies führt bei steigender Datensatz-Anzahl zu einer Verlangsamung der Filter-Ausführung. Die Informationen, nach welchen gesucht wird, sollten daher konzeptionell besser in einem anderen Feld(-typ) – ggf. zusätzlich – hinterlegt werden.
Weiterführende Informationen
https://wiki.postgresql.org/wiki/FAQ#How_do_I_tune_the_database_engine_for_better_performance.3F
https://blog.sqlauthority.com/2014/12/25/sql-server-performance-tuning-is-it-really-a-top-skills-for-a-sql-server-consultant-notes-from-the-field-059/