[寫在前面]
(1) 在 IIS 下,aspx 接到 request 後,再以 remoting call 的方式,呼叫一 windows service(主要是在本機上); 而這個 windows service 實做了所有的邏輯,並且會定時(如: 每一分鐘或每五分鐘)從 database 中重新載入資料形成 memory cache;並將結果回傳給 aspx,再由 aspx 組成網頁或字串以回應。
(2) aspx 與 windows service 會記錄各自所消耗的時間。
(3) environment: Windows 2003, .net framework 2.0 sp1.
[問題 & 狀況]
(1) aspx 記錄了呼叫 remoting call 到得到結果的時間,在某些時候,會遠超過 windows service 處理該次的時間。
而其中,消失的時間那裡去了呢?
會是因為 thread pool 滿了,而在等待嗎? CPU 太忙所導致嗎?
但是看起來,系統資源似乎還綽綽有餘啊!
(2) 而這種現象,在流量大(QPS高)時,尤其明顯。
(3) 有些機器很嚴重,但有些機器卻還可以接受。(ps: 機器等級差不多,執行內容都相同。)
[try + test]
(1) 修改 IIS - Application Pools - Performance - WebGarden - Maximum number of worker processes . 但未見改善。
(2) 修改 machine.config 中之 max worker thread (... 之類的設定),未見改善。(記得在 .net framework 1.1 蠻有用的)
(3) 叫用別台之 windows service,有的有改善,有的機器沒有改善。
(4) 修改 aspx,可呼叫多台 windows service。略有改善。
(5) 自己實做直接接下 port 80 之 request??? 先... 還是暫擱吧。
(6) 束手無策了好一陣子。
[step]
(1) aspx 在 Application_Start() 中,直接以 thread 方式載入了 windows service 之主要模組(says: module1),並以 static object 的形式存在。
(2) 由於 module1 載入 database 需要不少時間,因此以 thread 的方式載入,才不會卡住 main thread。
(3) 目前仍保留 windows service hosting another "module1"。
(4) 當 (2) 尚未完成時,aspx 會仍直接呼叫 windows service,雖然有時慢一點,但不會被卡住,仍可以回應。等到 (2) 完成了,就直接叫用 dll 中之 static module1。
(5) static module1 in (2) 仍會定時自 database 中更新 memory cache。
(6) 目前速度表現極好,在 0.1 秒的記錄,由以往一秒寫出十幾個以上,變成一秒3~5個,甚至沒有超過 0.1 秒。
(7) 尤要留意,在修改 web.config, 更換 dll 時,IIS 會 reload,會因為程式碼變得複雜而載入慢,有時會形成 server busy 的回應。
以前其實也有考慮過這樣子的做法,但擔心的是 IIS 的定期回收機制,會將 module1 回收掉,而再載入又需要一段時間,造成服務有問題。
目前上線未滿一天,待過了晚上大流量的考驗後,就可以逐步更新其他機器了。
觀察中........
[keywords]
IIS, ASP.Net, c#, remoting, remoting call, disappeared time, thread, worker thread
0 意見:
張貼留言