>>> 此贴的回复 >> 压缩,转换格式,序列化. http://ghd258.cnblogs.com/archive/2005/12/06/291653.html 看看这篇文章是否对你有帮助
>>> 此贴的回复 >> 我不懂WEB SERVICE,但从您的代码我只看到了二进制序列化,并没有看到压缩过程.而且, 就我的知识,WEB SERVICE似乎是使用XML格式传输数据,也就是说您的BINARY FORMAT数据 仍然需要通过XML的文本方式传输? 是否可以认为BINARY FORMAT 序列化与标准XML序列化相比缩小了可持续对象的体积,导致 传输数据量的减小?
>>> 此贴的回复 >> xml->压缩文件->数据流传输
>>> 此贴的回复 >> 现在，使用webService来取代Remoting接口也是个潮流（尽管性能有点下降，但是整体维护升级成本也下降了）。这时候，业务逻辑应该可以使用多个服务器组成集群。SQL Server这种中型数据库软件是很难分布在多个硬件上的，但是.NET组件还是很容易的。如果一个不行用3个，3个不行用11个甚至几十个服务器，使用负载平衡软件管理服务器群，直到性能达到要求才不增加服务器。通常在设计服务器群的时候，业务达到峰值的时候硬件资源应该还有20%的富余才好。
>>> 此贴的回复 >>
WebService如果以XML传输的话真的很不适合传送数据。 不过这只是XML的一种实现罢了，大可以去用别的方法代替。
用.Net Remoting是不是好点？
>>> 此贴的回复 >> 大数据量、交换频繁的情况下，不太建议使用Web Service。最可行的方式还是Sockets，当然Sockets的缺点是要向广域网开放一个端口。 Web Service传送的是未压缩的xml文件。此文件有不少控制符。再加上数据本身。其数据传输量将极大增加。 如果出于安全的考虑一定要用Web Service可以对数据进行打包处理。再对数据包压缩后传送。
楼主面对的系统我也将要面对，不过准备全国大数据量传送的东西。压力测试还没有做，也准备在平台中大量使用Web Service。为了网络传送瓶颈，在不影响平台使用的情况下，想了一些其他辅助手段。比如在数据传送极大量的时候，用移动硬盘等非网络介质进行数据迁移。
呵呵，其实有不少问题是可以用非技术手段实现的。主要是在可利用的资源中，利用技术协调好各方关系。 开阔思路吧，做项目最怕的就是钻牛角尖。
>>> 此贴的回复 >> 关键在于找到性能瓶颈在哪里。
问题不一定都是在 表示层和Web Service之间的数据传输，持久层，逻辑层都是有可能发生问题的。