線上訂房服務-台灣趴趴狗聯合訂房中心
發文 回覆 瀏覽次數:17848
推到 Plurk!
推到 Facebook!
[<<] [1] [2] [3] [>>]

無責任技評 : DataSnap

 
JL9168
中階會員


發表:133
回覆:223
積分:76
註冊:2011-09-29

發送簡訊給我
#62 引用回覆 回覆 發表時間:2015-04-22 12:49:49 IP:220.132.xxx.xxx 未訂閱
其實是有認真看完的,甚至去查了一些關於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

發送簡訊給我
#63 引用回覆 回覆 發表時間:2015-04-22 13:26:26 IP:220.132.xxx.xxx 未訂閱
為了測試DataSnap Server的強度,進行相對測試
壓力測試1. --- 針對Webbroker-DataSnap架構進行
D:\Class\ab -n 1000 -c 500 http://127.0.0.1/EchoString/TT334
的呼叫測試
DSServerClass的LifeCycle屬性不論是設定為Server / Session / Invocation 也好
在沒有放置任何資料集元件的狀況下,其實都是可以順利完成預設的測試次數的...
aftcast
站務副站長


發表:81
回覆:1482
積分:1762
註冊:2002-11-21

發送簡訊給我
#64 引用回覆 回覆 發表時間:2015-04-22 13:59:02 IP:114.32.xxx.xxx 訂閱
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

發送簡訊給我
#65 引用回覆 回覆 發表時間:2015-04-22 15:10:04 IP:220.132.xxx.xxx 未訂閱
果然出現意外的狀況:
跨機壓力測試下(條件 -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

發送簡訊給我
#66 引用回覆 回覆 發表時間:2015-04-22 15:21:04 IP:220.132.xxx.xxx 未訂閱
既然都跨機測試了,也來測試自製的ApServer
測試條件 (Port:211 , -n 60000 -c 10000)
R-P-S: 68.39 (Complete Requests)

JL9168
中階會員


發表:133
回覆:223
積分:76
註冊:2011-09-29

發送簡訊給我
#67 引用回覆 回覆 發表時間:2015-04-22 15:29:31 IP:220.132.xxx.xxx 未訂閱
如果連基本的 EchoString 指令都很難看,那更不用題更複雜的了
因為結果.....只會更難看!!
小弟比較了一下IdHttpServer的程式碼,發現其實用的都是一樣Socket模型;應該是程式沒有進行最佳化吧!!
繼承自 TDsServerModule 類型的實作問題更多;只能望而興嘆!!
或許應該作一些修正會好一些吧!! 先到這裡!!
aftcast
站務副站長


發表:81
回覆:1482
積分:1762
註冊:2002-11-21

發送簡訊給我
#68 引用回覆 回覆 發表時間:2015-04-22 18:14:18 IP:114.32.xxx.xxx 訂閱
謝謝 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

發送簡訊給我
#69 引用回覆 回覆 發表時間:2015-06-21 17:33:19 IP:220.132.xxx.xxx 未訂閱
終於把Delphi 的 DataSnap Server 調校的比較好些
測試條件 (Port:8080 , -n 40000 -c 10000)
R-P-S: 50.92 (Complete Requests)
已經很接近自製的ApServer了,就此打住!!
pcplayer99
尊榮會員


發表:141
回覆:733
積分:589
註冊:2003-01-21

發送簡訊給我
#70 引用回覆 回覆 發表時間:2015-09-15 13:10:24 IP:120.236.xxx.xxx 訂閱
我不熟悉最新的基于 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] [>>]
系統時間:2017-09-24 13:04:42
聯絡我們 | Delphi K.Top討論版
本站聲明
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。
2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。
3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇!