2011-07-26 170 views
0

我有一個Silverlight 4應用程序,它與WCF服務有很大關係。應用程序通常運行良好,對於一些重要的查詢,響應時間也很快。然而,最近它變得很慢,而且我很難排除原因。Silverlight/WCF應用程序突然傳輸速度非常緩慢

我的數據庫託管在遠程服務器上。該應用程序託管在同一臺服務器上。以下是我已經指出:

  1. 當我在本地運行的應用程序,使用ASP.NET作爲我的服務器而不是IIS,和我打通過本地主機的網站,該網站點擊遠程數據庫,速度快。

  2. 當我在本地運行應用程序,但使用遠程WCF服務而不是本地服務時,事情很慢。

  3. 當我通過Web運行應用程序時(即遠程應用程序又與數據庫位於同一臺服務器上,因此它們彼此是本地的),應用程序運行緩慢。這幾乎是什麼生產環境是...

  4. 當我登錄到服務器,並從服務器內擊中網站,事情是快速的。

  5. 對數據庫的查詢速度很快。手動在數據庫上運行查詢,會在瞬間產生結果。

  6. 使用WCFTestClient並擊中遠程WCF服務也非常快,並且幾乎立即轉身。

最後,當我用我的本地機器的擊中網站在網上,它訪問數據庫等預期的設置:

  1. 並不是所有的查詢做出同樣的反應。一些導致大數據集的較重查詢實際上有一個快速的響應時間。一些輕量級查詢 - 不帶連接的直接SELECT語句只生成一千字節的數據,需要更長的時間...大約30秒。有幾個查詢有時很快,有時很慢,但總是很慢的查詢是最差的。

關於服務器:

服務器是一個專用的服務器,我監視的CPU,它不是被任何徵稅。我正在使用IIS 7,Win Server 2K8和Sql Server 2K8。在過去的幾周裏,唯一改變的就是Windows的一些更新,一個人告訴我他們做了一些防火牆更改 - 這是我目前關於這個原因的理論,但我不知道還有什麼可以嘗試在這一點上,或者如何表明它是防火牆..

有什麼想法?

回答

0

提琴手。提琴手是答案(因爲它通常是)

如果您遇到類似的問題,希望我所學到的可以提供幫助。

這是我看到:

首先,同時使用Chrome瀏覽器/ IE探查時,它變得清晰,請求本身造成的滯後性,而反應相當快。

這導致我失去了兩種可能性:由於某些特定的配置,服務器在請求中造成滯後,這些配置在通過本地主機運行時不會看到,或者請求本身有問題。

在使用Fiddler獲取請求的完整視圖後,很明顯它是我發送的請求。其中一個作爲參數傳遞給我的WCF服務的對象具有一個屬性,該屬性在序列化時總計大約有1兆字節的數據 - 並且啓用了gzip。最初這個對象是一個相當小的對象,但隨着應用程序的增長,這個特定對象也在增長,導致突然減速。

爲什麼發生某些調用而不是其他調用的原因完全取決於哪個調用將此對象作爲參數。

在瀏覽網頁時,與通過本地主機進行比較的原因是,通過網絡,您不可避免地面臨提供商的上傳限制,以及一些跳躍,直到您打開服務器,與從本地主機到數據庫的直接連接。

課程總是傳遞最少量的信息,你可以逃脫。

1

很難根據你所描述的,我想你應該開始通過登錄數據庫的時間來分析您的應用程序,WCF請求處理時間等方面找出原因

一旦你的數據,你可以找到真正的原因。這就是我們一直在做的產品。

1

如果我不得不猜測,您正在經歷網絡延遲和不太理想的數據庫設計的組合。您對「小型」查詢的描述會比產生大型結果集的查詢花費更長的時間,這是您需要評估查詢計劃並確保它們使用正確索引(您使用索引的,對吧?)的經典指標。

我懷疑整理你的數據庫問題將解決你遇到的很多慢的問題;在memcached中緩存查詢結果或類似的東西將解決其餘的大部分問題。

一般來說,WCF是我尋找性能問題的最後一個地方 - 每次我在過去走過這個方向時,麻煩都成了我們的代碼; WCF的尺寸表現令人讚歎。

對不起,我不能更具體,但性能問題是相當具體的應用程序,我們沒有太多的信息繼續下去。

相關問題