>>> 此貼的回復 >> 壓縮,轉換格式,序列化. 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之間的數據傳輸，持久層，邏輯層都是有可能發生問題的。