iAnywhere.com - Performance-Tipps

Performance-Tipps

Im Folgenden finden Sie einige Tipps dazu, wie Sie die beste MobiLink-Performance erzielen.

Test Führen Sie vor dem Deployment Ihrer Software Tests mit großen Volumina unter Verwendung derselben Hardware und desselben Netzwerks aus, das sie für die Produktion verwenden wollen. Nutzen Sie die Tests, um mit folgenden Performance-Tipps zu experimentieren.
Konflikte vermeiden Vermeiden Sie Konflikte in Synchronisationsskripten. Anders ausgedrückt: Maximieren Sie die Parallelität.
Nehmen Sie zum Beispiel an, dass das Skript "begin_download" in einer Tabellenspalte die Download-Vorgänge mitzählt. Wenn mehrere Benutzer gleichzeitig synchronisieren, würde dieses Skript die Download-Vorgänge dieser Benutzer im Endeffekt serialisieren. Derselbe Zähler sollte besser im Skript begin_synchronization oder end_synchronization untergebracht werden, da diese Skripten unmittelbar vor dem Festschreiben aufgerufen werden.

Weitere Hinweise zu Konflikten finden Sie unter Konfliktsituationen.

Weitere Hinweise zur Transaktionsstruktur der Synchronisation finden Sie unter Transaktionen im Synchronisationsprozess.
Optimale Anzahl an Worker-Threads verwenden Setzen Sie die Anzahl der MobiLink-Worker-Threads mit der MobiLink-Option –w auf die kleinste Zahl, die Ihnen optimalen Durchsatz ermöglicht. Sie müssen wahrscheinlich experimentieren, um die günstigste Anzahl für Ihre Situation zu ermitteln.
Eine große Anzahl an Worker-Threads kann den Durchsatz steigern, da mehr Synchronisationen gleichzeitig durchgeführt werden können.

Die Anzahl der Worker-Threads niedrig zu halten, reduziert die Konfliktwahrscheinlichkeit in der konsolidierten Datenbank, die Anzahl der Verbindungen zur konsolidierten Datenbank und den für optimale Cache-Nutzung erforderlichen Arbeitsspeicher.

In Tests schneller Clients wurde z.B. festgestellt, dass etwa fünf Worker-Threads für einen optimalen Durchsatz gesorgt haben. Bei langsameren Clients sind mehr Worker-Threads erforderlich, um den Download-Durchsatz zu maximieren, und den besten Download-Durchsatz erzielt man, wenn die Anzahl der gleichzeitigen Upload-Vorgänge mit der Option -wu begrenzt wird. In Tests mit extrem langsamen Clients wurde der beste Durchsatz für Uploads und Downloads mit Hunderten von Worker-Threads erreicht, wobei nur fünf gleichzeitig einen Upload durchführen konnten. Beachten Sie, dass diese Zahlen aus einer bestimmten Testgruppe stammen. Jede Installation hat andere Merkmale und Sie müssen sie jeweils testen, um die optimalen Werte für "-w" und "-wu" zu erzielen.

Weitere Hinweise zu Worker-Threads finden Sie unter Anzahl der Worker-Threads.

Weitere Hinweise finden Sie unter Option -w und Option -wu.
Clientseitigen Download-Puffer für ASA-Clients aktivieren
Bei Adaptive Server Anywhere-Clients gestattet ein Download-Puffer einem MobiLink-Worker-Thread, den Download zu übertragen, ohne auf die Durchführung des Downloads durch den Client zu warten. Der Download-Puffer wird standardmäßig aktiviert. Der Download-Puffer kann nicht verwendet werden, wenn die Download-Bestätigung aktiviert ist (siehe nächster Punkt).

Weitere Hinweise zur Überwachung der Größe des Download-Puffers finden Sie unter Erweiterte Option DownloadBufferSize (dbs).
Download-Bestätigung für ASA-Clients nicht aktivieren Standardmäßig ist die Download-Bestätigung nicht aktiviert. Damit werden MobiLink-Worker-Threads freigegeben, die anderenfalls auf die Bestätigung eines erfolgreichen Downloads vom Client warten würden. Außerdem wird damit auch die vom Worker-Thread benutzte Verbindung freigegeben. Der MobiLink-Synchronisationsserver kann somit auch die Downloads puffern.
UltraLite-Clients puffern keine Downloads, sodass der Vorteil einer fehlenden Bestätigung von Downloads nicht so groß ist.

Weitere Hinweise zu Download-Bestätigungen finden Sie unter Erweiterte Option SendDownloadACK (sa).
Upload-Cachegröße festlegen Um zu vermeiden, dass der Upload-Cachespeicher auf den Plattenspeicher überläuft, setzen Sie die Größe des Upload-Cachespeichers so fest, dass er größer ist als der größte Upload-Datenstrom, multipliziert mit der Anzahl der Worker-Threads. Sie legen die Upload-Cachegröße mit der dbmlsrv9-Option –u fest.
Weitere Hinweise finden Sie unter Option -u.
Download-Cachegröße festlegen Um zu vermeiden, dass der Download-Cachespeicher auf den Plattenspeicher überläuft, setzen Sie die Größe des Download-Cachespeichers so fest, dass er größer ist als Ihr größter Download-Datenstrom, multipliziert mit der Anzahl der Worker-Threads. Sie legen die Download-Cachegröße mit der dbmlsrv9-Option -d fest.
Weitere Hinweise zur Festlegung des Speichers, der dem Download-Puffer zugewiesen ist, finden Sie unter Option -d.
BLOB-Cache festlegen Wenn Ihre Zeilen den Datentyp LONG VARCHAR oder LONG BINARY enthalten, können Sie vermeiden, dass der BLOB-Cache auf den Plattenspeicher zugreift, indem Sie die BLOB-Cachegröße so festlegen, dass sie mehr als doppelt so groß ist wie die größten BLOB-Daten in einer Zeile, multipliziert mit der Anzahl der Worker-Threads. Sie legen die BLOB-Cachegröße mit der dbmlsrv9-Option -bc fest.
Weitere Hinweise finden Sie unter Option -bc.
Maximale Anzahl an Datenbankverbindungen festlegen
Legen Sie die maximale Anzahl der MobiLink-Datenbankverbindungen so fest, dass sie der typischen Anzahl der Synchronisationskriptenversionen multipliziert mit der Anzahl der MobiLink-Worker-Threads plus Eins entspricht. Damit wird verhindert, dass MobiLink zu häufig Verbindungen trennen und wiederherstellen muss. Sie legen die maximale Anzahl der Verbindungen mit der dbmlsrv9-Option -cn fest.

Weitere Hinweise finden Sie unter MobiLink-Datenbankverbindungen und Option -cn.
Genügend physischer Arbeitsspeicher Stellen Sie sicher, dass der Rechner, auf dem MobiLink ausgeführt wird, über ausreichend physischen Arbeitsspeicher verfügt, um Upload-, Download- und BLOB-Cache sowie den sonstigen Speicherbedarf aufzunehmen.
Ausreichende Rechenkapazität Stellen Sie MobiLink ausreichend Rechenkapazität zur Verfügung, sodass die Verarbeitung durch den MobiLink-Server keinen Engpass darstellt. In Tests mit einer konsolidierten Adaptive Server Anywhere-Datenbank forderte MobiLink ein Drittel bis die Hälfte der von Adaptive Server Anywhere benötigten Rechenkapazität, wenn beide belastet und auf demselben Rechner ausgeführt wurden.
Minimale Ausführlichkeit für die Protokollierung Benutzen Sie die geringste, für Ihre Geschäftsanforderungen noch angemessene Ausführlichkeit für die Logausgabe. Standardmäßig ist die Logausgabe deaktiviert und MobiLink schreibt kein Log auf den Plattenspeicher. Sie können die Logausgabe mit der Option "-v" steuern und mit den Optionen "-o" oder "-ot" die Ausgabe in eine Datei aktivieren.
Als Alternative zu ausführlichen Logdateien können Sie Ihre Synchronisationen mit dem MobiLink Monitor überwachen. Der Monitor braucht sich nicht auf demselben Rechner wie der MobiLink-Synchronisationsserver zu befinden und die Wirkung einer Monitor-Verbindung auf die MobiLink-Server-Performance kann vernachlässigt werden. Weitere Hinweise finden Sie unter MobiLink Monitor.
Java- oder .NET im Vergleich zur SQL-Synchronisationslogik Bei der Verwendung der Java- oder .NET-Synchronisationslogik bzw. der SQL-Synchronisationslogik wurden keine bedeutenden Durchsatzunterschiede festgestellt. Die Java- und .NET-Synchronisationslogik haben jedoch etwas Overhead pro Synchronisation und benötigen mehr Speicher.
Außerdem wird die SQL-Synchronisationslogik auf dem Recher ausgeführt, auf dem die konsolidierte Datenbank läuft, während die Java- oder .NET-Synchronisationslogik auf dem Recher ausgeführt wird, auf dem der MobiLink-Server läuft. Die Java- und .NET-Synchronisationslogik kann zu bevorzugen sein, wenn die konsolidierte Datenbank stark ausgelastet ist.
Priorität der Synchronisation Wenn Sie bestimmte Tabellen haben, die häufiger als andere synchronisiert werden müssen, erstellen Sie eine eigene Publikation und Subskription für sie. Sie können diese Prioritätspublikation häufiger als andere Publikationen synchronisieren und andere Publikationen außerhalb der Zeiten der Spitzenbelastung synchronisieren.
Download auf die erforderlichen Zeilen begrenzen Achten Sie darauf, den Download auf die benötigten Zeilen zu begrenzen. Es ist einfacher, Synchronisationsskripten zu schreiben, die bei jeder Synchronisation alle Zeilen übertragen, doch der Download nicht benötigter Zeilen beeinflusst die Performance der Synchronisation.
Skriptausführung optimieren Die Performance Ihrer Skripten in der konsolidierten Datenbank ist ein wichtiger Faktor. Es kann hilfreich sein, Indizes zu den Tabellen zu erstellen, sodass Upload- und Download-Cursor-Skripten die erforderlichen Zeilen effizient finden können. Zu viele Indizes können Uploads jedoch verlangsamen.
Anzahl der Zeilen bei großen Uploads von ASA-Clients schätzen Sie können die Geschwindigkeit bei einem Upload einer großen Zahl an Zeilen erheblich steigern, indem Sie "dbmlsync" eine Schätzung der einzulesenden Zeilen übergeben. Hierzu verwenden Sie die dbmlsync-Option "-urc".
Weitere Hinweise finden Sie unter Option -urc.