使用web服务的紧凑框架太慢了！

Question

我有一个在CF3.5的PDA中的应用程序。我还用.NET3.5编写了一个WCF服务(WCF)。

有两种操作：

1) PDA向WS请求数据。WS返回大约500KB的sdf (sql server CE文件)。通信正常。大约5-10秒。

2)掌上电脑巡视采集数据，有时返回工作站并连接到WiFi。PDA通过从WS运行一个简单的true-false函数来检查是否存在通信故障，从而检查是否存在与WS的连接。如果不是，则PDA将其填充的sdf文件(700KB)发送到WS。从个人数字助理调用WS函数到在WS中运行该函数(这意味着数据已作为byte[]发送到该函数)大约需要30-40秒！

为什么在发送/接收方面会有如此大的差异？我应该检查哪些配置错误？

谢谢

Answer 1

这只是一种猜测，但很可能是将文件序列化为base64编码字符串的操作花费了大量时间。呼叫需要多长时间才能查看服务是否可用？如果这不是相同的30-40秒，那么你就知道这并不是对服务的实际调用需要时间，但是其他一些东西和序列化看起来肯定是这里的主要部分。

手动序列化文件需要多长时间(可能向导生成的代码在这里执行得很差)？我可能会检查一下，看看需要多长时间。我还会验证(使用Fiddler或类似工具)到底发生了什么，什么时候会发生。

Answer 2

对我来说，这听起来也像是序列化/ base64。您可能希望使用System.Diagnostics.Stopwatch来查看代码的哪些部分花费了这么长时间才能执行。由于WCF为CF中的代理生成了源代码，因此您也可以对其进行检测。如果你的瓶颈确实是序列化，你可能想要使用一些不同的东西，比如协议缓冲区(协议缓冲区的实现比WCF快得多，它解决了我以前遇到的一个性能问题)。您还可以尝试使用eqatec profiler，遗憾的是，它对于CF不再是免费的，但可以立即识别瓶颈。

Answer 3

好的。通过在发送文件之前和发送文件之后在byte[]上执行gzip压缩，解决了此问题。

感谢你们所有人的回答。