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.

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. Dadurch wird der Durchsatz eventuell gesteigert. 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:

Performance-Tests zeigen, dass der beste Upload-Durchsatz in der Regel mit drei bis zehn Datenbank-Worker-Threads erreicht wird. 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.

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. Geben Sie die Größe des Cache-Speichers für den MobiLink-Server mit der Option -cmax an.

Siehe mlsrv12-Option -cmax.

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.

Siehe mlsrv12-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 keine Downloadbestätigungstransaktionen verarbeiten müssen.

Siehe Erweiterte Option SendDownloadAck (sa).

Die Blockierung bei Downloadbestätigungen wurde abgeschafft, sodass alle Downloadbestätigungen im nicht blockierenden Modus verarbeitet werden. Dies führt zu einer besseren Performance. Beim 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.

Siehe mlsrv12-Option -w und mlsrv12-Option -wu .

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 Synchronisationsskriptversion 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:

mlsrv12 -c "dsn=SQL Anywhere 12 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.

Siehe mlsrv12-Option -cn .