Die folgende Liste enthält Vorschläge dazu, wie Sie die beste MobiLink-Performance erzielen.
Die nachfolgenden Aspekte tragen zum Durchsatz Ihres Synchronisationssystems bei: der Gerätetyp, den Sie auf Ihren entfernten Datenbanken ausführen, das Schema der entfernten Datenbanken, das Datenvolumen und die Synchronisationsfrequenz Ihrer entfernten Datenbanken, Netzwerkmerkmale (einschließlich für HTTP, Proxies, Webserver und Redirectors), die Hardware, auf der der MobiLink-Server ausgeführt wird, Ihre Synchronisationsskripten, das gleichzeitige Volumen von Synchronisationen, welchen Typ von konsolidierter Datenbank Sie verwenden, die Hardware, auf der Ihre konsolidierte Datenbank ausgeführt wird sowie das Schema Ihrer konsolidierten Datenbank.
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. 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. Derselbe Zähler sollte besser im Skript begin_synchronization, end_synchronization oder prepare_for_download untergebracht werden, da diese Skripten unmittelbar vor dem Festschreiben aufgerufen werden. Datenbanken werden somit nur kurzzeitig gesperrt.
Weitere Hinweise finden Sie unter Konfliktsituationen.
Weitere Hinweise zur Transaktionsstruktur der Synchronisation finden Sie unter Transaktionen im Synchronisationsprozess.
Setzen Sie die Anzahl der Worker-Threads der MobiLink-Datenbank mit der MobiLink-Option -w auf die kleinste Zahl, die einen optimalen Durchsatz ermöglicht. Sie müssen wahrscheinlich experimentieren, um die günstigste Anzahl für Ihre Situation zu ermitteln.
Eine große Anzahl von Datenbank-Worker-Threads kann den Durchsatz steigern, da mehr Synchronisationen gleichzeitig auf die konsolidierte Datenbank zugreifen können.
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 optimale Cache-Nutzung erforderlichen Arbeitsspeicher.
Weitere Hinweise finden Sie unter:
Bei SQL Anywhere-Clients gestattet ein Download-Puffer einem Datenbank-Worker-Thread von MobiLink, 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 Downloadbestätigung aktiviert ist (siehe nächster Punkt).
Weitere Hinweise finden Sie unter Erweiterte Option DownloadBufferSize (dbs).
Standardmäßig ist die Downloadbestätigung nicht aktiviert. Die Downloadbestätigung kann jedoch nützlich sein, um den entfernten Verarbeitungsfortschritt in der konsolidierten Datenbank aufzuzeichnen. Die blockierende Downloadbestätigung bindet eine Datenbankverbindung, während die entfernte Datenbank den Download durchführt. Wenn Sie die Downloadbestätigung verwenden, sollten Sie die nicht blockierende Downloadbestätigung verwenden. Die nicht blockierende Downloadbestätigung ist das Standardverhalten.
Weitere Hinweise finden Sie unter Erweiterte Option SendDownloadACK (sa) und Option -nba.
Es ist ineffizient, einen BLOB in einer Zeile einzuschließen, die häufig synchronisiert wird. 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 mlsrv11-Option -cn fest.
Weitere Hinweise finden Sie unter MobiLink-Datenbankverbindungen und 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.
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. Für eine optimale Performance 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. Verwenden Sie die Option -cm, um den Cache-Speicher für den MobiLink-Server einzurichten.
Weitere Hinweise finden Sie unter Option -cm.
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.
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. Weitere Hinweise finden Sie unter 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. Sie vermeiden ein solches Verhalten, indem Sie mit der Option -sm die maximale Anzahl an entfernten Verbindungen festlegen, die unter dem Grenzwert des Betriebssystems liegt.
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 -85 (SQLE_COMMUNICATIONS_ERROR). Die Clientanwendung sollte diesen Fehler bearbeiten und nach ein paar Minuten versuchen, die Verbindung erneut herzustellen.
Weitere Hinweise zur Option -sm finden Sie unter Option -sm.
Weitere Hinweise zu SQLE_COMMUNICATIONS_ERROR finden Sie unter 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 ist eine Verschwendung und wirkt sich nachteilig auf die Synchronisations-Performance aus.
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.
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.
Weitere Hinweise finden Sie unter Option -urc.
| Kommentieren Sie diese Seite in DocCommentXchange. Senden Sie uns Feedback über diese Seite via E-Mail. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |