使用Web服務的緊湊框架太慢了！

我有一個應用程序與CF3.5的PDA。我也在.NET3.5中編寫了一個web服務（WCF）。使用Web服務的緊湊框架太慢了！

有兩種操作：

1）PDA向WS詢問數據。 WS返回大約500KB的sdf（sql服務器CE文件）。溝通很好。大約5-10秒。

2）PDA收集收集數據，有時返回到一個站並連接到WiFi。 PDA通過從WS運行簡單的真假功能來檢查是否存在與WS的連接，以檢查是否存在通信故障。如果沒有，PDA將其填充的sdf文件（700KB）發送到WS。從WS調用WS函數直到函數在WS中運行（這意味着數據已經作爲字節[]發送到函數）需要約30-40秒的時間！

爲什麼發送/接收的差異如此之大？我應該檢查什麼錯誤配置？

感謝

來源

2010-09-14 gong

我通過從PDA到Java軸Web服務的ActiveSync連接發送/接收類似數量的數據。我發送〜100kb的數據，並接收〜500kb到1MB的數據。我把它作爲字符串發送，而不是字節[]。我不認爲我在上傳和下載時間方面經歷過任何大規模的不對稱。 – 2010-09-14 11:02:51

你的意思是字符串？以及如何將它再次轉換爲byte []？ – gong 2010-09-14 11:28:07

這只是一種猜測，但它可能是序列化的文件清楚交代抽空base64編碼字符串的行爲。通話需要多長時間才能看到該服務是否可用？如果這不相同的30-40秒，那麼你知道這不是對服務的實際調用需要時間，但其他和序列化肯定似乎是這裏的重要部分。

手動序列化文件需要多長時間（可能嚮導生成的代碼在這裏表現不佳）？我可能會檢查一下，看看需要多長時間。我還會驗證（通過Fiddler或類似的）究竟是什麼時候穿什麼。

來源

2010-09-14 13:12:38 ctacke

我做了一個測試函數，它將字節[]和序列化在我的PDA上的文本文件中。它大約需要7-10秒。沒有辦法接近30-40秒 – gong 2010-09-15 11:44:21

對我來說，這聽起來像是一個序列化/ base64。您可能希望使用System.Diagnostics.Stopwatch查看代碼的哪些部分需要很長時間才能執行。由於WCF在CF中爲代理生成源代碼，因此您也可以使用這些代理。如果你的瓶頸確實是序列化的，你可能需要使用不同的東西，比如協議緩衝區（protobuf-net的實現比WCF快得多，它解決了前一段時間我遇到的性能問題）。您也可以嘗試eqatec分析器，這個分析器可悲的是不再免費用於CF，但會立即識別瓶頸。

來源

2010-09-22 02:31:45 cloudraven

好的。這是通過在發送之前和發送文件之後在字節[]上執行gzip壓縮來解決的。

謝謝大家的回答。

來源

2010-09-29 09:31:11 gong

使用Web服務的緊湊框架太慢了！

回答

相關問題