Die nachfolgenden Aspekte tragen zum Durchsatz Ihres Synchronisationssystems bei:

Das Durchführen von Tests ist besonders wichtig. Führen Sie vor dem Deployment Tests unter Verwendung derselben Hardware und desselben Netzwerks aus, das Sie für die Produktion verwenden wollen. Testen Sie zudem möglichst mit derselben Anzahl an entfernten Datenbanken, derselben Synchronisationsfrequenz und demselben Datenvolumen. Das MobiLink Replay Tool kann diese Tests unterstützen. Siehe MobiLink Replay-Dienstprogramm (mlreplay) .

Experimentieren Sie während der Tests mit folgenden Performance-Tipps.

Vermeiden Sie Konflikte, und maximieren Sie die Parallelität in Synchronisationsskripten.

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. Es ist besser, diesen Zähler in das Skript begin_synchronization, end_synchronization oder prepare_for_download zu integrieren, da diese Skripten unmittelbar vor dem Festschreiben aufgerufen werden. Datenbanken werden somit nur kurzzeitig gesperrt. Ein noch besserer Ansatz wäre, nur nach entfernter ID zu zählen und die Gesamtzahl zu einem späteren Zeitpunkt per Abfrage zu ermitteln.

Siehe Konfliktsituationen.

Weitere Hinweise zur Transaktionsstruktur der Synchronisation finden Sie unter Transaktionen im Synchronisationsprozess.

Sie können entweder eine feste Anzahl von MobiLink-Datenbank-Worker-Threads wählen oder die Anzahl vom MobiLink-Server automatisch anpassen lassen. Wenn Sie eine bestimmte Anzahl verwenden, indem Sie die Option -wm nicht angeben, müssen Sie unterschiedliche Werte für die Option -w ausprobieren, um die kleinste Zahl zu ermitteln, die Ihnen den optimalen Durchsatz ermöglicht. Bei automatischer Anpassung legen Sie die maximale Anzahl der Datenbank-Worker-Threads über die Option -wm fest und -w wird verwendet, um die minimale und anfängliche Anzahl anzugeben. Wenn die Option -w nicht angegeben ist, lautet der Standardwert 5. Wenn Sie z.B. mit -wm 50 arbeiten und nicht die Option -w verwenden, passt der MobiLink-Server regelmäßig die Anzahl der aktiven Datenbank-Worker-Threads auf Werte im Bereich von 5 bis 50 an.

Eine große Anzahl von Datenbank-Worker-Threads kann den Durchsatz eventuell steigern, da zur gleichen Zeit mehr Synchronisationen auf die konsolidierte Datenbank zugreifen können. Damit geht jedoch ein erhöhtes Potenzial für Konflikte und Blockierungen einher.

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

Legen Sie in einem Produktionssystem die Optionen -w und -wu erst fest, nachdem Sie die optimalen Einstellungen für diese Optionen geprüft haben.

• Anzahl der Datenbank-Worker-Threads
• Automatische Anpassung der Datenbank-Worker-Threads
• mlsrv12-Option -wm
• mlsrv12-Option -w
• mlsrv12-Option -wu

Der MobiLink-Server kann die Anzahl der Datenbank-Worker-Threads automatisch basierend auf der Last anpassen, mit dem Ziel, den Durchsatz zu maximieren. Um diese automatische Anpassung zu aktivieren, legen Sie mithilfe der mlsrv12-Option -w die anfängliche Anzahl von gleichzeitigen Datenbank-Worker-Threads fest und mithilfe der mlsrv 12-Option -wm die maximale Anzahl von gleichzeitigen Datenbank-Worker-Threads. Der MobiLink-Server überwacht die Systemperformance und passt die Anzahl der Datenbank-Worker-Threads innerhalb der Parameter an, die durch die Optionen -w und -wm festgelegt sind, je nach den Anforderungen zu einem bestimmten Zeitpunkt.

Der mit der mlsrv 12-Option -wu festgelegte Wert, der für die maximale Anzahl von Datenbank-Worker-Threads steht, die gleichzeitig Uploads in die konsolidierten Datenbank übernehmen können, wird nicht automatisch angepasst. Wenn die Option -wu nicht angegeben ist, können Uploads von einzelnen oder allen Datenbank-Worker-Threads übernommen werden und die Anzahl der Datenbank-Worker-Threads ist variabel. Wenn der MobiLink-Server die Anzahl der Datenbank-Worker-Threads mit dem Ziel erhöht, den Durchsatz zu steigern, können kurzfristig Konflikte auftreten, bis dies erkannt wird und die Thread-Anzahl schließlich verringert wird.

Große Uploads können große Transaktionen in der konsolidierten Datenbank verursachen und große Transaktionen führen zu mehr Sperren in einer Transaktion. Dies erhöht die Anzahl der Blockierungen und Konflikte. Dies kann beträchtliche nachteilige Auswirkungen sowohl auf den Synchronisationsdurchsatz als auch auf den Gesamtdurchsatz der konsolidierten Datenbank haben. Kleinere Uploads reduzieren Blockierungen und Konflikte und können den Durchsatz signifikant verbessern.

Bei einem MobiLink-Synchronisationssystem mit entfernten SQL Anywhere-Datenbanken können kleinere Uploads über dbmlsync auf zwei Arten gesendet werden:

Auf der Serverseite kann die Performance mit der Option -tx optimiert werden, um eine Reihe von Transaktionen aus dem Client zu einer einzigen konsolidierten serverseitigen Transaktion zusammenzufassen. Diese Option ist insofern praktisch, als Sie nach dem Festlegen der clientseitigen Option -tx einfach optimieren können, ohne die Clients ändern zu müssen. Siehe mlsrv12-Option -tx.

Testen und optimieren Sie diese clientseitigen und serverseitigen Optionen im Hinblick auf maximalen Durchsatz.

Es ist ineffizient, einen BLOB in einer Zeile einzuschließen, die häufig synchronisiert wird, solange der BLOB unverändert bleibt. Um dies zu vermeiden, können Sie eine Tabelle erstellen, die BLOBs und eine BLOB-ID enthält, und die ID in dieser Tabelle referenzieren, die synchronisiert werden soll.

Legen Sie die maximale Anzahl der MobiLink-Datenbankverbindungen so fest, dass sie der Anzahl der Synchronisationsskriptenversionen multipliziert mit der Anzahl der Datenbank-Worker-Threads von MobiLink 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 mlsrv12-Option -cn fest.

Siehe MobiLink-Datenbankverbindungen und mlsrv12-Option -cn .

Stellen Sie sicher, dass der Computer, auf dem der MobiLink-Server ausgeführt wird, über ausreichend Arbeitsspeicher verfügt, um den Cache sowie den sonstigen Speicherbedarf aufzunehmen. Prüfen Sie die Möglichkeit, zu einer 64-Bit-Plattform zu wechseln, wenn der Server einen Speicher-Cache von mehr als 1,5 GB benötigt.

Die Anzahl der Synchronisationen, die aktiv verarbeitet werden, wird nicht durch die Anzahl der Datenbank-Worker-Threads begrenzt. Der MobiLink-Server kann für eine große Menge an Synchronisationen gleichzeitig Uploads entpacken und Downloads senden. Wenn ein Server mit dem Paging auf die Festplatte beginnt, wird der Durchsatz deutlich geringer. Deshalb ist es sehr wichtig, dass der MobiLink-Server über ausreichenden Cache-Speicher verfügt, um diese Synchronisationen ohne Paging auf die Festplatte verarbeiten zu können. Um zu erkennen, wann der Cache zu klein ist, suchen Sie im Serverlog nach Warnung 10082 oder dem Alarm "Cache ist voll" vom SQL Anywhere-Monitor für MobiLink.

Der MobiLink-Server stellt automatisch den erforderlichen zusätzlichen oder weniger Speicher-Cache zur Verfügung. Verwenden Sie die Optionen -cmax, -cmin und -cinit, um den Cache-Speicher für den MobiLink-Server zu steuern.

• mlsrv12-Option -cinit
• mlsrv12-Option -cmax
• mlsrv12-Option -cmin

Stellen Sie MobiLink ausreichend Rechenkapazität zur Verfügung, sodass die Verarbeitung durch den MobiLink-Server keinen Engpass darstellt. In der Regel benötigt der MobiLink-Server bedeutend weniger CPU als die konsolidierte Datenbank. Wenn Sie jedoch die Java- oder .NET-Zeilenbehandlung verwenden, nimmt der Verarbeitungsbedarf des MobiLink-Servers zu. In der Praxis handelt es sich bei Netzwerkeinschränkungen und Datenbankkonflikten eher um Engpässe.

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.

Wenn Sie den Assistenten zum Erstellen eines Synchronisationsmodells in Sybase Central benutzen, um Ihre MobiLink-Anwendungen zu erstellen, wird für jeden Download-Cursor beim Deployment des Modells automatisch ein Index definiert.

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 MobiLink-Monitor muss sich nicht auf demselben Computer wie der MobiLink-Server befinden. Außerdem kann die Wirkung einer Monitor-Verbindung auf die Performance des MobiLink-Servers vernachlässigt werden. Siehe MobiLink-Monitor.

Betriebssysteme schränken die Anzahl der gleichzeitigen Verbindungen ein, die ein Server über TCP/IP unterstützen kann. Wenn diese Grenze erreicht ist, was der Fall sein kann, wenn über 1.000 Clients gleichzeitig eine Synchronisation ausführen möchten, kann sich das Betriebssystem unter Umständen unerwartet verhalten, beispielsweise unerwartet Verbindungen beenden oder weitere Clients zurückweisen, die eine Verbindung herzustellen versuchen. Um dieses Verhalten zu verhindern, haben Sie folgende Möglichkeiten: Sie konfigurieren das Betriebssystem mithilfe der Option -nc so, dass es einen höheren Grenzwert für TCP/IP-Verbindungen hat, oder Sie geben mit der Option -sm die maximale Anzahl entfernter Verbindungen, die unter dem Grenzwert des Betriebssystems liegt, an.

Wenn ein Client versucht, mit einem MobiLink-Server zu synchronisieren, der seine mit der Option -sm festgelegte maximale Anzahl von gleichzeitigen Synchronisationen akzeptiert hat, empfängt er den Fehlercode -1305 (SQLE_MOBILINK_COMMUNICATIONS_ERROR). Die Clientanwendung sollte diesen Fehler bearbeiten und nach ein paar Minuten versuchen, die Verbindung erneut herzustellen.

Siehe:

• mlsrv12-Option -sm
• mlsrv12-Option -nc
• Verbindungsfehler

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.

Eine Synchronisation, die die direkte Zeilenbehandlung verwendet, belastet den MobiLink-Server mit einem großen Verarbeitungsaufwand. Daher benötigen Sie je nach implementierter direkter Zeilenbehandlung unter Umständen mehr Arbeitsspeicher (RAM), mehr Festplattenspeicher und eine größere CPU.

Wenn Sie bestimmte Tabellen haben, die häufiger als andere synchronisiert werden müssen, erstellen Sie eine eigene Publikation und Subskription für sie. Wenn Sie Synchronisationsmodelle in Sybase Central verwenden, können Sie dies durchführen, indem Sie mehr als ein Modell erstellen. Sie können diese Prioritätspublikation häufiger als andere Publikationen synchronisieren und andere Publikationen außerhalb der Zeiten der Spitzenbelastung synchronisieren.

Achten Sie darauf, nur die erforderlichen Zeilen per Download abzurufen, indem Sie z.B. die Zeitstempel-Synchronisation statt eines Snapshots verwenden. Der Download nicht benötigter Zeilen verschwendet Ressourcen und wirkt sich nachteilig auf die Synchronisations-Performance aus.

Zu häufige Synchronisationen können zu unnötigen Belastungen des MobiLink-Synchronisationssystems führen. Überprüfen Sie sorgfältig, wie oft Sie synchronisieren müssen. Testen Sie gründlich, um zu gewährleisten, dass die Performance-Erwartungen in der Produktionsumgebung erfüllt werden können.

Für SQL Anywhere-Clients können Sie 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.

Siehe dbmlsync-Option -urc.

Je mehr Synchronisation im Hintergrund erfolgt, umso weniger dringend ist es vom Gesichtspunkt des entfernten Benutzers aus, dass sie schnellstmöglich geschieht. Legen Sie Ihre entfernte Anwendung so an, dass sie im Hintergrund synchronisiert, damit entfernte Benutzer auch während der Synchronisation weiterarbeiten können.