Frequently Asked Questions
4. Scalability and throughput.
Q: how does SyncSmart perform in regards to scalability and throughput?
A: SyncSmart is non-invasive and does not impact applications; therefore developers can build and scale application functionality and application users to match the performance of the dbms and platform that they so choose. Because SyncSmart queries directly against the database using ODBC, it often has the same performance impacts on the database as a robust user might have. In theory, this allows for unlimited scalability for application users and makes overall performance a function of the robustness of the database and not of any one application. Currently, Data Safety Corporation's largest customer has 4,500 users that synchronize at random throughout the day. In addition, SyncSmart does not use transaction log files, which can build up and consume drive space when users do not synchronize for an extended period of time.
SyncSmart provides users the capability to perform ad hoc synchronizations throughout the day. This ad hoc functionality provides users with the flexibility to have their client database as up-to-date as they would like it to be. This flexibility benefit is provided as a byproduct of one of SyncSmart's core design concepts and is one of the key features of SyncSmart. SyncSmart leverages the inherent power of the application's dbms by using standard SQL queries of indexed data to extract and import changed records. By employing this methodology in its change processing, SyncSmart offers the maximum throughput possible for performing synchronization.
In regards to measuring throughput, while client side processing of SQL/DITM messages is important, throughput is measured at the server during peak synchronization times when the majority of application users initiate or pull synchronization (i.e., several hundred users synchronizing first thing in the morning). As noted previously, SyncSmart exports changes to a database by doing a query. Since the record versioning fields are indexed, these exports occur very quickly at dbms speeds. Importing SQL/DITM messages has more of an impact on throughput. SyncSmart has to process inserts, updates, deletes and collisions, as do all synchronization products. However, these messages can be queued for greater synchronization performance. In other words, the server can export changes for a user first and then process the users' imports off line after disconnecting.
A couple of other techniques can be used to further increase import performance. For one, SyncSmart can be configured to process multiple synchronizations on the server at once, essentially running imports in parallel. And secondly, SyncSmart can be configured to create multiple synchronization or SQL/DITM messages for each client database. Developers can then assign high and lower priorities to the data they want to synchronize
