Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
Need Guidance for Scalability RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote
    We currently have approximately 250 mobile clients that run a full version of Windows XP and SQL Express. These devices are syncing to a SQL 2008 database which has Change Tracking enable. Currently we are performing Download only syncs as the transactional data that gets pushed to the Servers is done through a Disconnected Service Agent. We are syncing 60 tables some of which contain between 200,000 and 300,000 records on an initial load. The client devices are on a wireless network (outside) and is shaky in most areas.

    As of right now we have a background sync that runs on a configurable time (set to 1 hour increments right now). The business would like to change this to be configurable by table, they would like 3 buckets: sync some tables at App launch, some at a short increment (every 5 minutes), and the rest at a long increment (every hour). My fear is the scalability. I currently use a direct connect sync. If I start syncing every 5 minutes for 250 clients what kind of issues would I come across?

    I'm really looking for guidance as to whether I should take an N Tier approach, use batching, etc?
    • Moved by Max Wang_1983 Thursday, April 21, 2011 10:45 PM forum consolidation (From:SyncFx - Microsoft Sync Framework Database Providers [ReadOnly])
    Thursday, October 29, 2009 5:45 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Here are some general guide lines for a high concurrent envrioment:

    1. do tune up for the performance, include your query logic, try to use stored proc, conflict resolution logic, your server envrioment( both sql and iss if Ntier ), probably indexed tables, use download only if necessary, sync only tables with changes, etc. this will help you scale up
    2. try to make the transaction shorter on the server, such as put table to differnt sync group and sync only tables with changes
    3. know you hardware limitation, if they holds the bottleneck, it probably is the time to scale out
    4. Ntier config allows you to put better throttling logic to control the load on SqlServer, but the entier sync duration could be longer ( end to end ), so please test this with your envrioment to get some baseline and the evaluate the configurations
    5. Batching can help reduce the memory usage, however in V1 ( I assume you use V1 with your own sql express provider ), batching support is limited and will also cause the end to end sync a bit longer, so please do test it and evaluate the solution

    hope this helps.

    thanks
    Yunwen

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Saturday, October 31, 2009 3:53 PM
    Moderator

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    If I'm completely way off base on this I need to know that too, so don't be afraid to post any comments.  :)
    Thursday, October 29, 2009 7:29 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Here are some general guide lines for a high concurrent envrioment:

    1. do tune up for the performance, include your query logic, try to use stored proc, conflict resolution logic, your server envrioment( both sql and iss if Ntier ), probably indexed tables, use download only if necessary, sync only tables with changes, etc. this will help you scale up
    2. try to make the transaction shorter on the server, such as put table to differnt sync group and sync only tables with changes
    3. know you hardware limitation, if they holds the bottleneck, it probably is the time to scale out
    4. Ntier config allows you to put better throttling logic to control the load on SqlServer, but the entier sync duration could be longer ( end to end ), so please test this with your envrioment to get some baseline and the evaluate the configurations
    5. Batching can help reduce the memory usage, however in V1 ( I assume you use V1 with your own sql express provider ), batching support is limited and will also cause the end to end sync a bit longer, so please do test it and evaluate the solution

    hope this helps.

    thanks
    Yunwen

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Saturday, October 31, 2009 3:53 PM
    Moderator
  • Question
    Sign in to vote
    0
    Sign in to vote
    Thany you for the information. Yes we are still on V1. Would it be beneficial to upgrade to V2?

    Tony
    Monday, November 2, 2009 3:46 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi,

    For hub-spoke providers, there is no functionality change between MSFv1 and MSFv2. 

    Thanks,
    Dong
    This posting is provided AS IS with no warranties, and confers no rights.
    Tuesday, November 3, 2009 1:39 AM
    Moderator