On Apr 23, 2011, at 3:54 AM, Steve Steinitz wrote: >> Sync Services scales poorly and works best with up to a few thousand >> small records. Creating multi-megabyte records, or millions of small >> records, will cause syncing to take a looooong time > > Thanks for that helpful rule of thumb. > > Our database is neither: a couple hundred thousand small records and perhaps > 30K new records per year. Would that be any more feasible?
No. 30,000 records is a lot to sync. >> (especially if you have identity properties set), > > Really? Identity properties slow it down? I thought it would be the > opposite. They do, because changes to identity properties force the mingler to check all other records of the same entity in order to see if they have identical values. If they do, then the mingler merges the records. >> and probably take several gigabytes of RAM just to run a session. > > Thanks for sharing your real-world experience. I was under the impression > that Leopard brought performance improvements to Sync Services. But that still takes a lot of memory. > That aside, an occasional 3-gigabyte of ram for a full pull from The Truth > would be fine. Only a hundred or two records change per day. And unless your users have more than 4 GB of RAM installed, then that will make the computer unresponsive for the life of the sync, which is probably not what you want to happen. >> We make a sync client, and before we built it for X86-64, we had >> several users crash it by attempting to sync too much data. > > Are you saying the X86-64 version works better? Works well? No, I'm saying that it will survive allocating more than 4 GB of RAM inside the process. 32-bit apps have a 4 GB RAM limit, and trying to go over that will crash the process. 64-bit apps are currently limited to allocating no more than the amount of built-in RAM plus the free space of the swap volume. >> If you need a multi-machine database-driven application, then you >> should use ODBC, not CoreData, with either MySQL or PostgreSQL or some >> commercial engine on the back end. > > Your advice is likely good but it doesn't sound much fun. I never said designing scalable systems was fun. But in the end, it's worth it. I just spent a month improving the scalability of a non-Sync Services sync engine to the point where it can process thousands of record changes in a time frame measured in a few seconds rather than a few minutes, and everyone's happy now. > Besides possible performance issues are there other serious Sync Services > issues? Not really. Sync Services was really glitchy in early versions of Tiger, but the serious serious problems were fixed in Leopard, or in Tiger point releases. As long as you're not still targeting Tiger users, the only thing you have to worry about are know-it-all clients that feel the need to "correct" changes you push to it (I'm looking at you, iCal), which is unlikely to happen if you're working with your own schema. Nick Zitzmann <http://www.chronosnet.com/> _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
