今天我终于设法运行客户端（windows mobile device） - wcf - sql server 2008同步（经过很多问题，主要是MS部分）
我做了测试。对于24 000条记录，快照的平均时间大约需要1分20秒。这是我下载Microsoft Sync for ADO.NET修复程序后的时间。
我还发现，50秒后数据库文件最终开始增长，大约需要25秒。
前50秒的框架是做什么的？加载和序列化数据？
在某些页面上，我发现了有关代理序列化的文章，该文章可以减少传输的数据量。
您知道同步过程是否可能从中受益？ （我的意思是修复后的Ado.net的MS Sync？）
我有什么办法可以加快这个过程吗？在我看来，24：24为24000是两倍太多......
答案 0 :(得分：1)
设备的同步框架存在两个主要问题：
你提到的热门修补程序尽可能地解决＃3问题，因此你无法做到这一点。
2号是同步框架的一部分，我担心没有什么可以做的。
对于＃1，这是50秒（大概30左右？）的大部分时间：当客户端收到数据集时，它必须反序列化整个流（流包含极其冗长的流） XML）在处理之前就可以开始了。对于大型数据集（10,000多行），这可能需要很长时间，并且一旦可用堆内存最大化，就可以（并且最终）甚至会导致Memory Crunch场景。
您引用的序列化代理方法将大大减少交换响应流的大小（在我的测试中，在某些情况下，它几乎减少了90％）。这肯定会在一定程度上改善响应时间，尤其是在网络连接吞吐量有限时。但是，在一天结束时，您无法解决在客户端处理开始之前必须将该流反序列化为DataSet的事实。
所有这一切：是的，代理序列化方法将减少传输的数据量，并且您可能会实现一些改进，但多少将取决于以下因素：
希望这有帮助！
答案 1 :(得分：1)
同步时会发生三件事： 1.它需要枚举已经发生的变化
需要将其发送到目的地
需要应用它
对于枚举，数据库的大小将产生很大的影响。即使没有任何变化，您也会对此检查产生一些性能损失。
对于项目＃2，数据集序列化是瓶颈。您可以选择使用数据集代理甚至压缩，但是您会遇到代理并进行压缩，您可能看不到大量的性能改进。
请参阅：Sync Framework WCF-based Synchronization for Offline scenario – Using custom dataset serialization
对于第1项和第2项，您可以对数据库应用相同的性能调整，例如仅通过过滤，调整索引等同步所需的行...
毕竟，Sync Fx应用程序就像任何其他数据库应用程序一样。
答案 2 :(得分：0)
如果您使用的是SyncFx 2.1库（SynchOrchestrator而不是SyncAgent），则SyncFx已经在使用DataSet Surrogate序列化 - 它是内置的。
为了避免与DataSet相关的内存不足问题，您可以查看批处理以找到限制每次同步可以发送的记录数的方法。它可以在某种程度上使用任何一组SyncFx库来完成，但对于2.1库而言比1.0库更具确定性。
*确定的： 2.1库允许您指定最大字节数， SyncFx会在最后一个适合其内部的完整行中自动切断 限制。我认为，使用1.0库是唯一的方法 批处理是指定最大行数，并希望（或仔细计算）该数据 不超过你想达到的限制。