locked
Recommended limits RRS feed

  • Question

  •  

    Do you have a general idea of what you are targeting as a theoretical maximum number of items that the framework can handle and still perform?  I know this will depend greatly on the synchronization provider but for now let’s go under the assumption that the provider will not be a limitation.

    • Moved by Max Wang_1983 Thursday, April 21, 2011 10:22 PM forum consolidation (From:SyncFx - Technical Discussion [ReadOnly])
    Tuesday, November 13, 2007 12:56 AM

Answers

  • Hi Sean,

     

    I am not aware of such limits. The runtime is very lightweight. As you said, the performance is bounded by the provider implementation and the underlying store. There are two things though that would slow down, although marginally:

     

    1- Number of nodes in the topology

    2- Number of unresolved conflict

     

    Both of these factors increase the size of the knowledge object that is a representation of the current state of each node. This knowledge objects is passed on to the remote node during sync to enumerate changes. The bigger the object that slower the transfer process. Also with more conflicts, it gets slower to check if a certain change need to be sent or not.

     

    From past experience building windows file system replication engine, these two factors do note cause a noticeable performance downgrade that you would worry about.

     

    Thanks

     

    Wednesday, November 14, 2007 6:44 PM
  • Also, the Sync session breaks up the sync in batches, so the providers have flexibilty in deciding what batch size is optimum for them, so that each batch will have the desired number of changes.

     

    Additionally, Knowledge is a very compact representation of what one endpoint knows about changes in other endpoints. Change enumeration and application deal with only a fixed sized metadata, and the item data is transferred only if needed. For example, in a one-way sync if the source and destination endpoints have a conflict, and the destination is choosen as the winner, no data transfer takes place. Also, if a conflict or change is skipped, data will not be transferred.

     

     

    Friday, November 16, 2007 12:43 AM
    Moderator

All replies

  • Hi Sean,

     

    I am not aware of such limits. The runtime is very lightweight. As you said, the performance is bounded by the provider implementation and the underlying store. There are two things though that would slow down, although marginally:

     

    1- Number of nodes in the topology

    2- Number of unresolved conflict

     

    Both of these factors increase the size of the knowledge object that is a representation of the current state of each node. This knowledge objects is passed on to the remote node during sync to enumerate changes. The bigger the object that slower the transfer process. Also with more conflicts, it gets slower to check if a certain change need to be sent or not.

     

    From past experience building windows file system replication engine, these two factors do note cause a noticeable performance downgrade that you would worry about.

     

    Thanks

     

    Wednesday, November 14, 2007 6:44 PM
  • Also, the Sync session breaks up the sync in batches, so the providers have flexibilty in deciding what batch size is optimum for them, so that each batch will have the desired number of changes.

     

    Additionally, Knowledge is a very compact representation of what one endpoint knows about changes in other endpoints. Change enumeration and application deal with only a fixed sized metadata, and the item data is transferred only if needed. For example, in a one-way sync if the source and destination endpoints have a conflict, and the destination is choosen as the winner, no data transfer takes place. Also, if a conflict or change is skipped, data will not be transferred.

     

     

    Friday, November 16, 2007 12:43 AM
    Moderator