無責任技評 : DataSnap |
|
JL9168
中階會員 發表:133 回覆:223 積分:76 註冊:2011-09-29 發送簡訊給我 |
其實是有認真看完的,甚至去查了一些關於WinSocket的資料
會這樣說,是想點出關於原廠在於DataSnap上的實作上是有一些值得提出疑問的地方 像是 TServerMethods1 = class(TDSServerModule) 這一行,去查詢TDSServerModule這個類別 TDSServerModuleBase --> TProviderDataModule --> TProviderDataModule 然後看到了TProviderDataModule類別原型 其中 TProviderDataModule = class(TDataModule) private FProviders: TList function GetProviderCount: Integer; 也就是說,如果你在ServerMethodsUnit1上面放了一堆DbConnection , DBQuery , DataSetProvider....這樣的實作能經得起多少人同時連線呢?? 放置的資料集元件越多,資源吃得越兇;更有甚者SQL指令還不使用Where條件......後果就能輕易想像.....
編輯記錄
JL9168 重新編輯於 2015-04-22 13:04:04, 註解 無‧
|
JL9168
中階會員 發表:133 回覆:223 積分:76 註冊:2011-09-29 發送簡訊給我 |
|
aftcast
站務副站長 發表:81 回覆:1485 積分:1763 註冊:2002-11-21 發送簡訊給我 |
JL兄,我建議是否可以從另一台 pc 去測。即 pc1 (server),pc2(ab測試程式),因為經過了網路卡與種種的環境來看,比較準。若是 127.0,0,1 其實是會 "by pass" 很多東西的,比如網卡就不會有關連。也不能用 vm ,因為還是同一台。就是要"物理上" 不同的機器。
可以的話, c 值拉更高, echostring 換成 dataset或是較複雜一點的json。 我期待那樣的結果。 。。 不急就是。 ===================引 用 JL9168 文 章=================== 為了測試DataSnap Server的強度,進行相對測試 壓力測試1. --- 針對Webbroker-DataSnap架構進行 D:\Class\ab -n 1000 -c 500 http://127.0.0.1/EchoString/TT334 的呼叫測試 DSServerClass的LifeCycle屬性不論是設定為Server / Session / Invocation 也好 在沒有放置任何資料集元件的狀況下,其實都是可以順利完成預設的測試次數的...
------
蕭沖 --All ideas are worthless unless implemented-- C++ Builder Delphi Taiwan G+ 社群 http://bit.ly/cbtaiwan |
JL9168
中階會員 發表:133 回覆:223 積分:76 註冊:2011-09-29 發送簡訊給我 |
果然出現意外的狀況:
跨機壓力測試下(條件 -n 1500 -c 500), (1) TServerMethodsUnit1中繼承TDsServerModule的方式來實作,某些狀態下甚至通不過測試,每秒處理的指令數也---> "很低" (2) TServerMethodsUnit1中繼承TComponent的方式來實作,數據簡略如下 2-1. LifeCycle:[Session] --> R-P-S = 33.99 (Complete Requests) 2-2. LifeCycle:[Invocation] --> R-P-S = 36.27(Complete Requests) 2-3. LifeCycle:[Server] --> R-P-S = 33.52(Complete Requests) (3) TServerMethodsUnit1中繼承TDtaModule的方式來實作,數據簡略如下 3-1. LifeCycle:[Session] --> R-P-S = 36.87(Complete Requests) 3-2. LifeCycle:[Invocation] --> R-P-S = 37.17(Complete Requests) 3-3. LifeCycle:[Server] --> R-P-S = 34.95(Complete Requests) -C 參數要超過一千........待測...... |
JL9168
中階會員 發表:133 回覆:223 積分:76 註冊:2011-09-29 發送簡訊給我 |
|
JL9168
中階會員 發表:133 回覆:223 積分:76 註冊:2011-09-29 發送簡訊給我 |
|
aftcast
站務副站長 發表:81 回覆:1485 積分:1763 註冊:2002-11-21 發送簡訊給我 |
謝謝 JL兄的實測! 讚喔! ^_^
===================引 用 JL9168 文 章=================== 如果連基本的 EchoString 指令都很難看,那更不用題更複雜的了 因為結果.....只會更難看!! 小弟比較了一下IdHttpServer的程式碼,發現其實用的都是一樣Socket模型;應該是程式沒有進行最佳化吧!! 繼承自 TDsServerModule 類型的實作問題更多;只能望而興嘆!! 或許應該作一些修正會好一些吧!! 先到這裡!!
------
蕭沖 --All ideas are worthless unless implemented-- C++ Builder Delphi Taiwan G+ 社群 http://bit.ly/cbtaiwan |
JL9168
中階會員 發表:133 回覆:223 積分:76 註冊:2011-09-29 發送簡訊給我 |
|
pcplayer99
尊榮會員 發表:146 回覆:790 積分:632 註冊:2003-01-21 發送簡訊給我 |
我不熟悉最新的基于 Indy 的 DataSnap 的架构。大概看了一下里面的 Source code,没太看明白。像 TServerMethods1 = class(TDSServerModule) 这样的东西,不应该是每个客户端连接创建一个的么?
如果每个客户端连接,Server 端就创建一个。那么,问题就很简单了:客户端需要向服务器端获取数据或者提交数据,就连接。操作完成,马上断开连接。那么,理论上,服务器端的这个 TServerMethods1 对应该客户端的 Object 就应该释放掉。那么,普通的情况下,就算有 100 个客户端,真正并发的同时连接可能就只有5-10个了。 更进一步,如果这个 TServerMethods1 的 Object 并不是立即释放,而是客户端断开连接后,这个 OBJECT 就被放进一个 POOL 里面。当有客户端要来连接的时候,从 POOL 里面把它拿出来使用。那么,它就免去了重新和 DataBase Server 建立连接的时间消耗。 具体 DataSnap 的架构,我不是很清楚。我仅仅是推论,它应该这样做。当然,最近几版的 Delphi 里面很多代码,比较差劲,看起来像是没什么经验的新人写的,说不定就没做。 我比较不爽 DataSnap 的,是它完全采用 Object 的架构,而不是以前 WebService 时采用的 Interface 的架构。以前 WebService 的 Interface 的架构,非常优雅、简单,好理解。很明显地就能看出来 TSoapDataModule 是每次客户端的访问,它就创建一个 Object。但似乎是没有 Pool 机制。 我前面说的 Pool 机制,WINDOWS 的 COM 就提供了。如果用 Delphi 来做,也可以利用 WINDOWS 系统的 COM 的 POOL 机制。这个李维大师的书里有讲到,我也实际测试过。 至于前面讨论的 INDY 的 TCP 的问题,同步、异步的机制问题,这个应该是 DELPHI 最大的问题:没有一套能承受很大访问量的 TCP 框架,而 INDY 的质量还不够好。 只是,我在 XE5 底下,测试过 Indy TCP Server 和 Client,一个 Server,开 500 个 Client,每个 Client 不停地干活:1. 连接,2. 发数据,3. 断开连接。这样对 server 进行狂轰滥炸跑一小时,发现 Indy TCP Server 很稳定,居然没出问题。 最后:多层的编程大忌,就是客户端连着服务器端,一直连着不释放。但现在这个 DataSnap 的架构似乎是鼓励你连着不释放(比如它的服务器端的 CallBack 机制,就必须是客户端要一直连着服务器)。而 delphi 的 WebService 那套框架,却非常优雅。而且 WEB 本身就是每次访问完,一定会断开连接的。一个 HTTP 访问结束,客户端和服务器端的 TCP 连接就断开了。所以,我现在宁愿继续用 WebService ,暂时还不考虑这个 DataSnap。 ===================引 用 JL9168 文 章=================== 其實是有認真看完的,甚至去查了一些關於WinSocket的資料 會這樣說,是想點出關於原廠在於DataSnap上的實作上是有一些值得提出疑問的地方 像是 TServerMethods1 = class(TDSServerModule) 這一行,去查詢TDSServerModule這個類別 TDSServerModuleBase --> TProviderDataModule --> TProviderDataModule 然後看到了TProviderDataModule類別原型 其中 TProviderDataModule = class(TDataModule) private FProviders: TList; \------> 個人覺得這個屬性物件才是造成多人連線導致資源不足的元兇!! function GetProviderCount: Integer; 也就是說,如果你在ServerMethodsUnit1上面放了一堆DbConnection , DBQuery , DataSetProvider....這樣的實作能經得起多少人同時連線呢?? 放置的資料集元件越多,資源吃得越兇;更有甚者SQL指令還不使用Where條件......後果就能輕易想像..... |
本站聲明 |
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。 2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。 3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇! |