Synchronization 微软Ado.Net同步-效率如何提高？

今天，我终于成功地运行了客户端（WindowsMobile设备）-wcf-SQLServer2008同步（在出现了许多问题之后，主要针对MS部分）

我做了测试。对于24000条记录，快照的平均时间约为1分20秒。这是我下载Microsoft Sync for ADO.NET修复程序之后的时间

我还发现，50秒后，数据库文件最终开始增长，大约需要25秒

框架在前50秒做了什么？加载和序列化数据

在某个页面上，我找到了关于代理序列化的文章，它可以减少传输的数据量

您知道同步过程是否会从中受益吗？（我是指修补程序后Ado.net的MS Sync？）

---

我能做些什么来加快这个过程吗？在我看来，24000的1:24太多了一倍…

设备的同步框架有两个主要问题：

它通过ADO.NET数据集交换数据

在客户端，在“初始”同步上设置客户端数据库以支持同步需要大量开销

SQL CE在插入时非常慢

您提到的热修复程序尽可能地解决了#3的问题，因此您在这方面可以做的事情不多

第二个是同步框架的一部分，恐怕对此没有什么可做的

至于#1，这就是50秒（也许30秒左右）的大部分时间被使用的地方：当客户端接收到数据集时，它必须对整个流进行反序列化（其中流包含非常详细的XML），然后才能开始处理。对于大型数据集（10000多行），这可能需要很长时间，而且一旦可用堆内存耗尽，甚至可能（最终）导致内存紧缩

您引用的序列化代理方法将大大减少正在交换的响应流的大小（在我的测试中，在某些情况下它几乎小90%）。这肯定会在一定程度上提高响应时间，尤其是在网络连接吞吐量有限的情况下。然而，在一天结束时，您无法回避这样一个事实：在客户端处理开始之前，必须将该流反序列化到数据集中

所有这些都表明：是的，代理序列化方法将减少传输的数据量，您可能会实现一些改进，但改进程度取决于以下因素：

• 数据集的大小
• 可用设备内存量
• 设备处理器速度和可用性

---

希望这有帮助

如果您使用的是SyncFx 2.1库（SynchOrchestrator不是SyncAgent），那么SyncFx将已经在使用数据集代理序列化-它是内置的

为了避免与数据集相关的内存不足问题，您可以查看批处理，以找到限制每次同步可发送的记录数的方法。在某种程度上，这可以通过任何一组SyncFx库来实现，但2.1库比1.0库更具确定性

*确定性： 2.1库允许您指定最大字节数， SyncFx将自动在最后一整行中剪切适合该行的内容 限制。我相信，使用1.0库是 做批处理就是指定最大行数，并希望（或仔细计算）数据 不要超过你想要达到的极限

---

同步时会发生三种情况： 1.它需要枚举已发生的更改

它需要将其发送到目的地

它需要应用它

对于枚举，数据库的大小将产生很大的影响。而且，即使没有任何更改，您也会为此检查招致一些性能损失

见：

对于第2项，数据集序列化是瓶颈。您可以选择使用数据集代理，甚至是压缩，但在这里，您会遇到执行代理和压缩的问题，您可能看不到大规模的性能改进

见：

对于第1项和第2项，可以应用与数据库相同的性能调整，例如通过筛选、调整索引等仅同步所需的行

---

毕竟，Sync Fx应用程序与其他数据库应用程序一样。

同步过程真的会导致设备出现“内存不足”问题吗？老实说，我认为该框架已经“准备好”将如此大的数据传输到sql ce（或者我可能是天真地这么认为的…），我最初的手工同步过程，由于遇到反序列化问题，多次调用以获取部分数据。。。顺便说一下，在“直接模式”下对sql ce的插入非常快，codeplex上还有一个用于批量插入的类，它似乎非常快……是的，它肯定会导致OOM条件。取决于行数和每行的宽度等，但在某一点上，你会击中它。请记住，每个进程最多分配32MB的可用空间。此外，根据您使用的操作系统（WM6.1及以上版本在某种程度上缓解了这一问题），所需的系统库使用了大量内存。呃，有时我真的认为，如果我准备了一个sdf文件，在服务器端有更大的表，并将其上传到移动设备上，效果会更好。。。。无论如何，谢谢你的帮助！是的，如果不需要双向同步，我们的许多应用程序就是这样工作的。我成功地将代理序列化从1:20降到了0:40。这是一个差距：）对，那是我以前的同步版本，当我意识到它不会在WM上运行时，我很失望。