Der Schlüssel zum optimalen Durchsatz während der MobiLink-Synchronisation besteht darin, mehrere Synchronisationen gleichzeitig und effizient auszuführen. Um mehrere gleichzeitige Synchronisationen zu ermöglichen, verwendet MobiLink Pools von Datenbank-Worker-Threads für unterschiedliche Aufgaben. Ein Pool ist dem Lesen von Upload-Daten aus dem Netzwerk und dem Entpacken derselben gewidmet. Ein anderer Pool von Threads, die als Datenbank-Worker-Threads bezeichnet werden, wendet die Upload-Daten auf die konsolidierte Datenbank an und stellt Daten bereit, die per Download aus der konsolidierten Datenbank abgerufen werden sollen. Ein weiterer Pool von Datenbank-Worker-Threads dient zum Verpacken und Senden der Download-Daten an entfernte Datenbanken. Jeder einzelne Datenbank-Worker-Thread verwendet eine eigene Verbindung mit der konsolidierten Datenbank zum Übernehmen und Abrufen von Änderungen mithilfe der Synchronisationsskripten.

Konfliktsituationen

Der wichtigste Faktor ist, in den Synchronisationsskripten Datenbankkonflikte zu vermeiden. Genau wie bei allen anderen Multi-Client-Einsätzen einer Datenbank müssen Sie die Datenbankkonflikte minimieren, wenn Clients gleichzeitig auf eine Datenbank zugreifen. Datenbankzeilen, die bei jeder einzelnen Synchronisation geändert werden müssen, können die Anzahl der Konflikte erhöhen. Wenn Ihre Skripten z.B. einen Zähler in einer Zeile aktivieren, kann dies zu einem Engpass führen.

Synchronisationsanforderungen werden akzeptiert (bis zu der Grenze, die mit dem Option -sm festgelegt wurde) und die hochgeladenen Daten werden gelesen und entpackt, so dass sie für den Datenbank-Worker-Thread bereit sind. Falls es mehr Synchronisationen als Datenbank-Worker-Threads gibt, werden die überschüssigen Synchronisationen in die Warteschlange gestellt, wo sie auf einen freien Datenbank-Worker-Thread warten.

Sie können die Anzahl der Datenbank-Worker-Threads und Verbindungen steuern, aber MobiLink wird immer dafür Sorge tragen, dass für jeden Datenbank-Worker-Thread zumindest eine Verbindung vorhanden ist. Wenn mehr Verbindungen als Datenbank-Worker-Threads vorhanden sind, sind die überzähligen Verbindungen inaktiv. Überzählige Verbindungen sind nützlich beim Einsatz mehrerer Skriptversionen, wie unten noch beschrieben wird.

Anzahl der Datenbank-Worker-Threads

Abgesehen von Konflikten in Synchronisationsskripten ist die Anzahl der Datenbank-Worker-Threads die wichtigste Einflussgröße für den Synchronisationsdurchsatz. Die Anzahl der Datenbank-Worker-Threads steuert, wie viele Synchronisationen gleichzeitig in der konsolidierten Datenbank ablaufen können.

Um die optimale Anzahl von Datenbank-Worker-Threads zu bestimmen, müssen Tests durchgeführt werden.

Durch die Erhöhung der Anzahl der Datenbank-Worker-Threads können mehr überlappende Synchronisationen auf die konsolidierte Datenbank zugreifen, wodurch der Durchsatz gesteigert wird. Es nehmen jedoch auch die Ressourcen- und Datenbankkonflikte zwischen den überlappenden Synchronisationen zu, wodurch einzelne Synchronisationen mehr Zeit in Anspruch nehmen können. Mit steigender Anzahl der Datenbank-Worker-Threads geht der Vorteil der gleichzeitigen Synchronisationen durch die Kosten der längeren Einzel-Synchronisationen verloren, und durch das Hinzufügen weiterer Datenbank-Worker-Threads sinkt der Durchsatz. Durch Experimentieren können Sie die optimale Anzahl der Datenbank-Worker-Threads für Ihre Situation ermitteln. Folgende Hinweise mögen dabei hilfreich sein:

In Performance-Tests wurde festgestellt, dass der beste Upload-Durchsatz mit einer relativ geringen Anzahl von Datenbank-Worker-Threads erzielt wird. In den meisten Fällen sind dies drei bis zehn Datenbank-Worker-Threads. Variationen hängen ab von Faktoren wie Art der konsolidierten Datenbank, Datenvolumen, Datenbankschema, Komplexität der Synchronisationsskripten und eingesetzte Hardware. Zu einem Engpass kommt es gewöhnlich aufgrund einer Konfliktsituation zwischen Datenbank-Worker-Threads, die die SQL-Anweisungen des Uploadskripts in der konsolidierten Datenbank gleichzeitig ausführen.

Wenn die blockierende Downloadbestätigung aktiviert ist, hängt die optimale Anzahl von Datenbank-Worker-Threads für Downloads von der Bandbreite zwischen Client und MobiLink und der Verarbeitungsgeschwindigkeit der Clients ab. Bei langsameren Clients werden mehr Datenbank-Worker-Threads benötigt, um die optimale Download-Performance zu erzielen. Der Grund dafür ist, dass Downloads mehr Rechenkapazität auf der Clientseite und weniger in der konsolidierten Datenbank erfordern als Uploads. Wenn die blockierende Downloadbestätigung aktiviert ist, werden Datenbank-Worker-Threads blockiert, bis die entfernte Datenbank den Download ausgeführt hat. Für die nicht blockierende Downloadbestätigung sind keine weiteren Worker erforderlich.

Wird keine Downloadbestätigung verwendet (Standardeinstellung), ist die Bandbreite zwischen Client und MobiLink weniger maßgeblich, da ein Datenbank-Worker-Thread zur Verarbeitung anderer Synchronisationen frei steht, während die anderen Threads den Download senden. Die Anzahl der Datenbank-Worker-Threads ist daher weniger entscheidend.

Es können weitaus mehr Downloads gleichzeitig gesendet werden als Datenbank-Worker-Threads. Für eine optimale Download-Performance ist es wichtig, dass dem MobiLink-Server ausreichend Arbeitsspeicher (RAM) zur Verfügung steht, um diese Downloads zu puffern. Andernfalls wird der Download seitenweise auf der Festplatte gespeichert, und die Download-Performance kann beeinträchtigt werden. Verwenden Sie die Option -cm, um die Größe des Cache-Speichers für den MobiLink-Server festzulegen.

Weitere Hinweise finden Sie unter Option -cm.

Falls der MobiLink-Server mit dem Paging auf die Festplatte beginnt (möglicherweise, wenn zu viele Downloads gleichzeitig verarbeitet werden), sollten Sie die Option -sm benutzen, um entweder die Anzahl der Datenbank-Worker-Threads zu verringern oder die Gesamtanzahl der Synchronisationen, die aktiv verarbeitet werden, zu begrenzen.

Weitere Hinweise finden Sie unter Option -sm.

Wenn Sie die Downloadbestätigung deaktiviert lassen (Standardeinstellung), kann dies die optimale Anzahl der Datenbank-Worker-Threads reduzieren, da die Datenbank-Worker-Threads nicht darauf warten müssen, dass Clients Downloads durchführen.

Weitere Hinweise finden Sie unter Erweiterte Option SendDownloadACK (sa).

Wenn Sie die Downloadbestätigung verwenden, wird bei der nicht blockierenden Downloadbestätigung eine bessere Performance erzielt (verglichen mit der blockierenden Downloadbestätigung). Im nicht blockierenden Bestätigungsmodus verwendet der Server den Datenbank-Worker-Thread erneut, während die entfernte Datenbank den Download anwendet. Das bedeutet, dass die Anzahl der Datenbank-Worker-Threads möglicherweise nicht erhöht werden muss, was zu einer verbesserten Performance führt.

Um den besten Download- und Upload-Durchsatz zu erzielen, bietet MobiLink zwei Möglichkeiten: Sie können eine Gesamtzahl von Datenbank-Worker-Threads angeben, damit die Downloads optimiert werden. Sie können auch die Anzahl begrenzen, die gleichzeitig Uploads übernehmen kann, um den Upload-Durchsatz zu optimieren.

Mit der Option -w wird die Anzahl der Datenbank-Worker-Threads gesteuert. Der Standardwert ist fünf.

Mit der Option -wu wird die Anzahl der Datenbank-Worker-Threads begrenzt, die gleichzeitig Uploads in die konsolidierte Datenbank übernehmen können. Standardmäßig können alle Datenbank-Worker-Threads Uploads gleichzeitig übernehmen, doch dies kann zu schweren Konfliktsituationen in der konsolidierten Datenbank führen. Mit der Option -wu können Sie diese Konfliktsituation eingrenzen, während Sie weiter eine große Anzahl von Datenbank-Worker-Threads haben, um das Abrufen von Download-Daten zu optimieren. Der Parameter -wu hat nur dann einen Einfluss, wenn der Wert unter der Gesamtzahl der Datenbank-Worker-Threads liegt.

Weitere Hinweise finden Sie unter Option -w und Option -wu.

MobiLink-Datenbankverbindungen

MobiLink erstellt für jeden Datenbank-Worker-Thread eine Datenbankverbindung. Mit der Option -cn können Sie angeben, dass MobiLink einen größeren Pool von Datenbankverbindungen herstellen soll. Die überzähligen Verbindungen bleiben jedoch inaktiv, es sei denn, MobiLink muss eine Verbindung trennen oder eine andere Skriptversion verwenden.

Es gibt zwei Fälle, in denen MobiLink eine Datenbankverbindung trennt und eine neue herstellt. Der erste Fall tritt ein, wenn ein Fehler auftritt. Der zweite Fall, wenn der Client eine Synchronisationsskriptversion anfordert und keine der verfügbaren Verbindungen diese Synchronisationsversion bisher verwendet hat.

Wenn Sie normalerweise mehr als eine Skriptversion benutzen, können Sie die Notwendigkeit, dass MobiLink Verbindungen trennen und wiederherstellen muss, reduzieren, indem Sie die Anzahl der Verbindungen erhöhen. Sie können die Notwendigkeit vollständig beseitigen, wenn die Verbindungsanzahl für Synchronisationen gleich der Anzahl der Datenbank-Worker-Threads multipliziert mit der Anzahl der Skriptversionen ist.

Ein Beispiel zur Optimierung von MobiLink für zwei Skriptversionen finden Sie in der folgenden Befehlszeile:

mlsrv11 -c "dsn=SQL Anywhere 11 Demo" -w 5 -cn 10

Da die maximal für Synchronisationen nutzbare Anzahl der Datenbankverbindungen gleich der Anzahl der Skriptversionen multipliziert mit der Anzahl der Datenbank-Worker-Threads ist, können Sie -cn auf 10 setzen, um zu gewährleisten, dass die Datenbankverbindungen nicht übermäßig getrennt und geöffnet werden.

Weitere Hinweise finden Sie unter Option -cn.