最近數日，副站連po他對datasnap的相關經驗與學習心得等。我也從中接收了一些不錯的資訊。謝謝他 ^_^

在觀看了幾篇後，覺得蠻有意思的，於是乎就引我稍深入的去了解DataSnap。我必需承認，在過去，我大概只用了3次以內的datasnap。經過三天左右的深入點的研究後，我也產生了一些看法，部份看與與 ruru 副站不太一樣。本來在心遲疑是否要把心得與看法分享一下，原因當然是怕會讓人誤會我在打對台。但又想想，一件事情有多種看法是有幫助的，無論是正面的意見或是負面的意見，但值得去思考並從中得取價值。於是決定還是來寫一下幾天來的心得。在寫之前，我突有所想，在年輕時有一位c 者作--候捷，他曾寫過「無責任書評」與「深入淺出mfc」等等好書。我喜歡他的許多觀點，無論就技術上的，或是學習方法上的經驗。因此，我想開始寫一些「無責任技評」。

什麼是無責任技評?從候先生在199x年繼承了「李宗盛的無責任樂評」寫了「無責任書評」的一致想法 : 就是"本人"對一些東西暢所欲言、不必負責。你也可以當做是一種「個人」對事情的看法。當然，非常有主觀意識，也不見得是正確。因此，也不必非常過度的認真。「技評」，我用這二個字的原因是我並非要評論某書，而是想評論某些「資訊技術相關的東西」。本次，就從我對 datasnap 這項技述來評論一下。

評論，不代表都以負面觀點來看待，雖然用負面的說詞比較嗨，也比較容易激發感覺，但我還是儘量的照自己的想法把正面與負面的都說一下。另外，評論是對「事」而不對「人」(至少儘力而為)。而我本身也樂意被批論，當然最好是就技術上，非人格上喔。哈哈。

本文即將開始:

「不管是黑貓或白貓，能抓老鼠的都是好貓」。

「不管是玩具車或是一般車，都是好車」-- 蕭沖

為什麼我提到玩具車? 因為近來我發現不少技術都像是玩具車。玩具車沒什麼不好，你試想若世上沒玩具車，那小孩子們的樂趣就少很多了。小孩當然只能開玩具車來滿足他們的愉快。大人們當然就是想開一般車 : 跑車，高級房車… 。生產玩具車也是能賺錢的，個人覺得目前embarcadero公司在delphi/cb一些技術上就是在生產玩具車。

於是就來評論一下這款 datasnap 玩具車。在評論前，不免俗的要先對一些名詞做些定義，緊接著就要用「深入淺出」的方式 -- 化整為零，解構後吸收至內力，然後感覺其實也沒什麼 -- 來做一些結論。

「何為n層架構?」喔 ruru 他在他的那篇也有開宗名義的提到。不過，我當然是有所不同的看法，所以才再提。軟體的架構除了寫成"一個" exe 檔外，其實還有一些選擇。原因不外乎軟體若深入的解析，大致上可以分成「展示層」、「商業邏輯層」、「資料層」。展示層就是「畫面」與人互動的畫面，也就是一般說的 UI 。「商業邏輯層」指的就是因應不同的領域，對資料做一些計算(演算)的處理，比如會計軟體就要實作「借貸法則」。而資料層呢? 當然就是對計算或是記錄的結果來做存與取。簡單的說它可以是一些ini檔，data檔，dbase檔，或是RDBMS(關連資料庫)，如 mysql，mssql… 。 以上是說明了三層的架構。那麼有一些人所提的 三 層以上的架構是啥? 個人覺得是將 三層 「水平」的在分出來的層。比如把「邏輯層」再次水平分出幾個層次，意即一種分散式處理。

所以，小結一下三層架構:

1層: 將軟體3層的內涵全都寫在一個程式裡面，無論是畫面，計算，對資料的存取(指比如隨機讀文字檔)通通一個程式全部搞定。這種也很常見。

2層: 最一般的說法是將「資料層」與其他二層分離。通常，這種資料層都是用高級資料庫，比如 mssql，mysql，oracle…。2 層沒什麼特別的，就單純的是把一些資料的存取由高級資料庫來擔任。程式人員不必去寫「二元樹」等資料結構演算法，因為他們被database給做掉了。這種軟體也是很普遍。

3層: 就是把軟體的內函三層都分出來了。其中，展示層--畫面 被移出變成一個模組或執行檔。邏輯層則變成了另一個模組或程式。而資料層依然是高級資料庫本身。換句話說，至少有三個模組(dll 或 exe) 分離出來，並擔任各自的責任。


三層架構的名詞定義完。接著就來談一個相關的東西 -- 瘦客戶 -- 不是客戶他很瘦喔。英文是Thin Client。我平常比較喜歡用英文技術詞，比較不會意思出入。比如若是我來翻譯，我可能叫它 -- 輕量級客戶端。在 過去 midas4 至 2010年前比較常被提到。他的意思就是希望 end user的電腦上只要裝一些很輕量的程式 (意味著重點在畫面)，就可以跑。為了要輕，當然就要把一些層給移除了。於是就有3層開發的一些研究與討論。當時，網路的技術在 web 2.0 前後，最常被說的就是 web application。他就是標準的 3 層 thin client。

以web架構來看。browser本身就是負責 畫面 。(僅管目前前端javascript 過度重用，導致愈來愈不輕)。故 browser就是第1層。而第二層是 web server 後端程式，比如 iis 配上 asp，或是 apache配上php。中間層負責把user送來的資訊加以整理、計算後輸出。第三層，依然是資料庫層。僅管軟體內函三層不一定要是機器分開三台，但通常是會分開，才能將優點更突出。小結web開發之三層。

第1層 : browser ，使用DHTML javascript 。
第2層 : web server，使用 cgi / php/ asp/ isapi/ asp net/ jsp …
第3層 : SQL server: Orcale, MSSQL, MySQL....

以上三層定義與應用大致上說明完畢。

待續‧‧‧‧‧

PS. 請看倌們思考此刻 2015年，我們需要 瘦客戶 嗎? cpu 超快，記憶體很大，硬碟更是大到不像話… 瘦客戶有什麼好處? 你是delphi / cb 人員的話要怎麼來寫類 web application 三層?

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

編輯記錄

 2層架構 vs 3 層架構，誰輸誰贏?

事實上「在資料傳輸上」，2層唯一比較明確輸3層的只有一個:

◎當資料庫與程式在不同機器上時，且程式需透過網際網路連絡 database 時， 3 層比2層安全非常的多。

比較安全是因為程式在網際網路的任何地點上不能直連 db，意味著無法直接控制整個db。

其他方面， 3層 與 2層 很難說誰的效能好。

◎「連線數過多，效能變差? 」 其實… 「一般」來說，連線數少，效能才差!

假始 20人有資料的請求，建立20條連線絕對比建立 1條或2、3條快非常多。喔，當然，這與 ruru 的說法有些不同，是吧? … 這… 請自己判別吧，我只能說依我的了解是這樣的。給你一個例子，假如某個 query 要查很久，比如查30秒鐘才會完成。那麼若你僅建立一條連線，那麼第 20 人要收到資料時，因為排隊大概也好幾分鐘。現在的機器與database，絕對可以承受多連線同時處理，並發揮多核的效能。故連立少數連線來服務多數人，效能一般是差!

那麼3層的資料存取是否有機會勝過2層? 當然有機會… 但前題是，中間層要能夠建立cache。(但，事實上db本身就會一些cache)。如果說，中間層可以把被要求過的 table (在記憶體中) cache住，等下一個連入請求時，再給他們，這就3層就可能勝出。 話說到此，先別高興，

◎datasnap在2009前，根本就是沒有，或是部份有cache的能力! 這就是我說他是玩具的道理。暫時不講細節。換句話說，2009年前，3層的架構(指機器分開的)肯定慢! 除了安全性，我看不出有太多理由用 datasnap。

◎直連db server的通訊協定是快速的。也就是說，你的程式向database要求資料，與回傳資料的那些"流"，在網路線上，是快速的二進位。相對的，若是透過中間層… 那肯定是較慢的。你有想過當你的程式與中間層間的資料是長怎樣的嗎? 二進位? 字串? 包很大?。這方面… 2層一定勝3層。

以上是就「資料傳輸來論」，2層通常贏。那麼三層分立的優勢 : 瘦客戶 在哪裡? 喔… 再來一個思考題，假設你要求一個極大的質數，這需要很多的cpu運算才能達成。若家用pc算起來有點吃力(雖然現在家用也很強)。那麼，把這樣的請求交給雲上的「超級中間層」處理後再回傳給你，肯定比較快。說到這裡… 你可能又覺得3層好…但依然別先高興，

◎datasnap在2009前，根本無法(至多極小部份)做「商業邏輯運算」。它只會依你的請求，幫你從db上取資料送給你。是跛腳的中間層!


結論: 總的來說，2層架構輸在 安全性，其他方面則不一定是輸的，而且經常是贏的!


PS. 真心歡迎大家來踢館、指教、指正。有討論才會愈進步。 對於技術，本人不在意面子。除非是針對人身啦!

未完，待續…

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

編輯記錄

其實我開始的時候就在想要不要針對我的 DataSnap 主題另開吐槽串。

想想可能沒人理就作罷，想不到蕭大俠就先開炮了。哈！

在 多層，究竟有幾層？試著定義一下。 一文中。

我就有提到關於三層的內容，也許我講的還太模糊。

硬是忽略 Database 的處理，對於「層數」，我會在下個版本再做修正說明。

附帶補充，我手繪的圖形架構是完整的三層架構！

===============================

「效率」在這邊又細分：
就傳輸效率來說，三層就像是自排車，不論效率再怎麼提升，所能提供的效能，
就只能趨近於，頂多等於，絕對不可能「優於」手排二層。

也就是沒有經過第三手封裝，最原始的資料串流(Binary Stream)。

就「連線數」來說，
我指的是「常時而多數的兩層連線，會造成資料庫主機的反應變慢。」
而蕭大所提到的是中間層的執行緒處理，
就例子來看是對應到 DataSnap 中「Single Instance」的概念。

Cache 在 Delphi 2009 以前來說就有了，那時就有提到 MIDAS Connection Pool 的概念。
但必須搭配 COM / MTS 進行實作，在 Client 端也要採行 TDCOMConnection 的連線模式才能做到。

但 MTS 好實作、好部署、好控制嗎？
還有 DCOM 連線在跨網際網路下的安全性問題，好解決嗎？

於是它幾乎被放棄了。

====================================

「除了安全性，我看不出有太多理由用 DataSnap」

這應該也可以用在 Web Application 上頭，就目前我所知道的。
Web Application 在複雜應用上，用戶端的回饋反應也絕對不會太好。

現在 Web 應用也因為偏重 JavaScript 進行開發，所以 PHP / ASP 等泛中間層語言的操作就越來越簡化。

太繁瑣的處理的大都還是會丟給 Database 去處理，在 PHP / ASP 下做絕對快不了。

現在 Web 前端幾乎就要把 PHP / ASP 的工作做完了，泛中間層只需要橋接結果寫回資料庫。

而 JavaScript 現在幾乎是 Browser 的戰場，看看各大瀏覽器的發展，JavaScript 支援及處理是首推特色！

嗯……看似跛腳的中間層卻好像是未來的發展呢。(笑)

DataSnap 與其說是玩具車，我倒覺得像是概念車，但大多數的人會拿概念車做成玩具車。
可以做 Lexus 或 Luxgen；要做成 BMW 或 Benz 就要買泊來品(3rd)；想打造瑪莎拉蒂或法拉利，這不在 DataSnap 的範籌內。

感謝蕭大百忙中提供 DataSnap 評析，有新的感想也歡迎繼續指教！

編輯記錄

我也來說一下連線數的問題

要賣錢的資料庫，比如 MSSQL，通常連線數是要算錢的，預算有限的狀況之下，連線數是有限的

而一般二層式的應用程式一旦連上資料庫，就不放手了

為什麼不放手？方便嘛！懶嘛！

使得有限的連線數被佔用，無法有效的利用

而三層式應用程式的資料庫連線是中間層使用，只要是「無狀態」的中間層，資料庫連線可以比二層式有更有效的運用

小弟淺見供大家參考

------
歡迎參訪 "腦殘賤貓的備忘錄" http://maolaoda.blogspot.com/

回覆我的好友ruru :

還是要再強調一下，我寫這評論不是針對你的文章，更不是針對你。我真心期待你把你的經驗一直寫下去，我都很認真的在看，在學。所以，這絕對不是吐槽串。更進一步的說，未來我有時間，也會寫對不同技術的一些看法，並且評論之，純當記錄與愉樂。

關於你說「連線數」的問題。我覺得我與你應該有部份是一樣的想法。但可能又有一小部份不一樣，或者因為說詞不同而誤會。你說:
「常時而多數的兩層連線，會造成資料庫主機的反應變慢。」
我覺得上面的句子應該是 「長時而多數的連線，會造成資料庫主機的反應變慢」。並非吹毛求疵。而是對db來說，連線就是連線，理當不強調二層或是三層的連線。而「長時且多數」(我想常是你打錯字吧?但這不是重點，除非你真的是常) 是個關鍵。照我個人的看法與說法，我會說「許多長時間閒置的連線，會造成db主機反應變慢」。或許你是一樣的看法，只是說詞略有不同。這個「許多」、 「長時間閒置」是關鍵，這就是我在後面要批論 datasnap是玩具的原因之一。待後面再回頭論述。

不過，我看不出來在 datasnap2009版前(以下都改寫datasnap02，表舊的，datasnap09表新的，數字是年份左右)不自己改裝的情形下，要如何讓這種情形變沒有。簡單講就是，在普通的datasnap寫法上，一個client端的請求，比如要一個table的資料，一定會有一個與db的連線。換句話說，是一個請求對一個db連線。我說過，除非有cache的能力，不然請求一次，就一定會有一條與db的連線 (不管是重連，或是新連，就是一條連線在上面)。於是，若 20 人的程式同時請求中間層，以datasnap02普通實作上來看，就是20條 db 連線。完全看不出連線數有少。我會這樣說，當然是基於一些觀察與研究。我在稍後會解構 datasnap02，就應該會清楚些。容我後面講到時，再回頭補充。

你提到:
「Cache 在 Delphi 2009 以前來說就有了，那時就有提到 MIDAS Connection Pool 的概念。
但必須搭配 COM / MTS 進行實作，在 Client 端也要採行 TDCOMConnection 的連線模式才能做到。」

以上完全與我這幾天的研究有相反到。我已確認的是，當使用TWebConnection時，才會有cache的能力，以下是書本的貼文:

Object Pooling

Finally, a Web connection can use object pooling. This feature enables the server to create a pool of multiple server instances for client requests. This way, the DataSnapServer doesn't use the resource for the remote data module and database connection unless it's actually needed.

Object pooling gives you the ability to set a maximum for the number of instances of the remote data module inside the DataSnap server application. Whenever a client request is received, the DataSnap server checks to see if a free remote data module exists in the pool. If not, it creates a remote data module instance (but never more than the specified maximum number of remote data module instances) or raises an exception with the message Server too busy. The remote data module, in its turn, services the client requests and duly waits for the next one. After a certain period of time without client requests, the remote data module is freed automatically (by the object pooling mechanism).

上面的話來自 Borland C BuilderT 6 Developer's Guide : 第21章。詳做法可參考它內文。

至於用com 來實作pool，我只能說依我對com元件的了解，當然是可以。但把 com 與 TRemoteDataModule 如何掛在一起，我是不清楚。這問題也是在後面我解構 datasanp之 com 元件架構會提到。到時候可以再反回來看。不過，稍早的文我就提到「部份的」有cache的能力。指的就是這個，只是想稍後再提之。

DCOM 連線在跨網際網路下的問題，我覺得最嚴重的不是安全性。是跨不了防火牆。防火不易過的情形下，什麼都很難談。這就是為何datasnap02 會有另外的二種選擇。HTTP 或 TCP 。我可以稍透露DCOM是基於 UDP 的。細節後面講。

最後，最最讓我感到有趣的是，你提到了現在的web application，把前端的javascript提的很高，許多的演算都在前端，而中間的反而變成了資料的轉運站之類的。我看到此，想法很多，真的也覺得這是很有趣的理解與想法。我覺得開心，因為有觸發。

你說的，與觀察的，真的很真。所以，我很想說，我們來發明一個叫「瘦中間」或「瘦中間件」的詞吧。(偷笑)。 在我解說三層架構裡，我提到軟體的「內涵可以大致上分3層」。但沒人說哪一層應該比較瘦。僅管過去大家認為應該要瘦客戶。但也沒說一定不能瘦中間。但我思考後的看法呢?

基於3層架構的情形下，win form程式，一般而言瘦中間是比較好。以會計軟體來說，若是加減等運算都要往中間去送，那麼軟體的反應肯定差，體感不佳! 除非該win form程式用到相當大的運算。

基於3層之web app，我覺得現在的程式人員，把客戶端搞肥真的很爛! 我曾使用舊的機器，比如win2000時代的配備，來看現在的網頁，只能說慘到機器掛點。這表示什麼? browser裡的程式太肥了! 即使是現在的pc，在開了10來個網頁的時候，也會發生主機發燒，記憶體不足的情形。這都是誰的錯? 馬的，就是 「肥客戶」的錯! 多數網頁又不是在搞網頁式商用app，比如會計web版。把pc搞熱，怎麼不去把 雲 的主機搞爛。難道能稱之為雲的主機比user的主機爛嗎? 「這種肥客戶」的網頁思維不可取! 換句話說，就是把 ajax 的技術爛用了。ajax 是為了某些時候網頁不能好 一直 refresh。一方面一直refresh體驗差一點，二方面因為http是無態的(注:我會深刻的在後面提什麼是有態/無態)，所以後端程式為了讓畫面看起來好像沒refresh過，要做很多的處理。這些時候都是ajax使用的時機。但不是隨時連入後面要資料，然後在前面就搞起來了…

我不能要求寫web的人照我的想法寫，但我個人真的很厭惡那樣的爛用。網頁還是要 瘦客戶 才佳!

以上，都是基於一定要3層的情形。但許多的時候，若網路是封閉的，比如在企業內部，能用2層就用2層，絕對效能高。

評論datasnap是玩具這件事，絕不是基於到目前為止的一些說法而已。我感覺，好像要寫很多才能完全這評論。我依然覺得它就是玩具，連改裝都難，當然，說「無法」改裝是太過了。但說它先天很不足，極難改裝肯定是真的。所以它是 … 玩具。是不是玩具，可以在完結篇時再來重新探論吧!

經過你的回覆，我又吸收與思考了一些想法，謝謝! 也希望有不同想法的人可以提出看法。激發一下。

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

真的很開心，好友 sryang也來論。這樣大家level更快昇等!  ^_^

你說的我認同。而關於「無態」中間層的連線可以比2層更有效。我的看法是:

因為無態，所以可以把資料集(dataset)重複使用，拿去給需要的人。並不需要再次向db要。

不知你的看法是這個意思嗎?

若是，我只能說，datasnap要如何達答這樣的任務? 「無態」可以。但 dataset重複使用? 在 datasnap02(指舊的)的做法，大致只有用 webconnection (即使用 isapi 配 iis )的情形下，配合 object pool (我上面有貼文)。但那不是預設就可以，要調整。另，在新的 datasnap09下，就容易一點點。用方法回傳資料集合…但不能選 per session，也不能是 invoke… 否則都無法「重複使用」。詳我會在後面談。

或是你有別的做法可以讓 dataset重複使用? 這方面你經驗足，我應該有不少沒想到的… 還請多多指教。

^^

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

DataSet 重複使用是一個很大的課題，我說的並不是這一部份，而是讓有限的資源，也就是資料庫連線數得以充分利用，以舒緩很貴的連線數閒置浪費的問題

至於 cache 因為這個問題太大了，以我有限的腦筋解決不了這個問題的，所以還是讓 DBMS 來處理就好

------
歡迎參訪 "腦殘賤貓的備忘錄" http://maolaoda.blogspot.com/

 接下來要進入「深入淺出」「庖丁解牛」的時刻。評論一個技術，對我來說，當然不能只是簡單的一些概念、想法就來評，至少也要有一些深入的技術分析，這樣才能服眾!

「什麼是MIDAS ? 米達斯? DataSnap ? 資料快照? 資料快擷? 」

通通都只能一個包裝名詞而已啦，這樣比較嚇人，比較神祕，比較好賣?!

⓪ DataSnap 根子裡，它就是 RPC (Remote Process Call)，或是用 OOP 的概念來說，它是 RMI (Remote Method Invocation)。

拆解了第一層後，不禁要問，那什麼又是 RPC/RMI ? 用白話一點的說法，就是在二個程序(process)間，由其中一個叫用另一個的物件方法。我們知道，在物件導向的實作上，我們會在類別裡實作許多的方法，並且在需要的時候初始化它 (create/new)。產生了一個instance後，就開始用它的一些方法。而RMI 所關注的問題是，要如何的在不同的process間叫別人的物件方法。當然，若是同一個process，沒什麼特別的，就new/create就用了。

RMI 的重點又是什麼? 喔，這可以用一點直覺來看待就理解。
1/ 要呼叫對方的哪個物件，哪個方法?
2/ 參數與回傳值要怎麼表達給對方的process知道?
3/ 當被叫的process幫忙產生物件後，要何時把物件殺死?
4/ 在呼叫端要如何使用遠端的物件?
5/ 用什麼方式傳遞過去?

這些問題，在windows上，就是 DCOM 的實作。跨平台就是CORBA的實作。於是，要了解 DataSnap的真面目，就要了解 RMI 他所處理的事務，也就是上面列出的5個點是怎麼實作的。

其次，在此先說明DataSnap02扣出SOAP外，另三種模式通通都是基於DCOM -- 它們是 :
1/ 原生 DCOM
2/ HTTP 包DCOM
3/ TCP 包DCOM

別以為 http 或是 tcp 就不是DCOM，通通都是。就好比香蕉禮盒被芭樂盒子包起來，表皮看是芭樂，打開後依然是香蕉。

更重要的是，DataSnap02 其實只用了RMI的一個小小的「一個」功能 -- 單純的傳請求的資料集。直到DataSnap09，才算是比較完整一點的RMI ，因為新的DataSnap很容易自訂型別，參數也比較多元一點。(註:完稿後發現，ruru也指出，DataSnap02也是可以自訂"有限制"的方法，方法的參數要是 com 元件的variant型別，詳參考 docwiki.embarcadero.com/RADStudio/XE7/en/Calling_Server_Interfaces )

直到你對RMI很了解後，你就很明白的知道為什麼server端要拉某些元件，而client端又要配合某些元件。這決對不是靠背的，是由理解中可知道為何需要某些元件。也因此才能夠正確地，發揮所長地操控所有物件，尤其是針對DataSnap09。

下一篇要細說DCOM，以助理解RMI。

未完待續…

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

編輯記錄

自訂方法！嘿嘿，DataSnap02 就已經出現囉！但我不明白蕭大所提的「改裝」之意？

就像 Sryang 大說的，要保留 TDataSet 等物件的重複使用，在 DataSnap 下，是無法採用的。
重複使用 DataSet，那一堆 Client 該如何更新？再來找 TDataSet Post？這……

DataSnap 頂多只能做到保留 Remote DataModule Instance，省下 Client 再次建立及初始化 RDM 所需要的時間。。

Object pooling 章節中所提到的，在 Delphi 和 C Builder 是以不一樣的方式實做，以 Delphi 來說：
可參考：三層應用 webconnection與httpsrvr.dll與IIS的有關的問題

再看 C Builder........... 只能說 CB 真的是小三的孩子，連實作都很硬。

再談 Cache 的結論：RDM HttpSrvr.dll TWebConnection 才能夠享受 Object pooling 的效果。

再到 Doc 裡查了一下，發現 RegisterPooled 開放的連接池，僅保留第一個 Instance ，後面的參數是設定 Client 連線數的上限。
和 COM Object Pooling 還是不太一樣。

又， Sryang 大所說「很貴的連線數閒置浪費」的問題，係指在中間層可設定同時連線的上限(剛好 RegisterPooled 就是做這個工作)，這樣就可以規避 Client 數的版權費用！

DBMS 的 Cache，這個方法讚！

YA！可以看到蕭大來「庖丁解牛」了！這應該是 2015 年開始以來最精彩的時刻了！

編輯記錄

 

— 連線數過多效能會變差的原因

假設一個連線數就是一個櫃台，今天有很多人來銀行提領現金。

3層架構有分有狀態及無狀態兩種模式，以下是以無狀態的模式講解

「孩子，別傻了」

用「櫃台」的概念講解真是開大絕了(用櫃姐會更好！！！)

讚一個！

===================引 用 Jasonwong 文 章===================
... 43...

「孩子，別傻了」

感謝 jason 也來幫忙解說。三層的解釋加入了歴史的註解，更加清析了它的意義!

關於「連線數過多效能會變差的原因」(註:指客戶應用程式看到的效能，或是流量。這也是客戶最重視的! 若單對 db 本身來說，它忙不是重點，只要不是瞎忙)。我想做最後一次的個人見地解說，希望能把問題更見其真面目。

就我來看，「連線數過多」並不是根源，甚至不是一種"錯"。僅管"表象上來看"，多數的情形下，連線過多效能會開始轉差。

什麼才是真的"錯"與根源? 「閒置過久」。因之前已經回覆ruru同樣的說法，但我覺得應該有必要再淺出一點。


假如一群人去賣當勞點餐。

櫃台很長，可以排10行的客戶。但很不幸的，事實上能服務的點餐人員就只有一人…

店長說:「我覺得若能儘量在"同時間"處理客戶的點餐，那應該可以很快的把所有人的餐都點完」。

於是請一群人排成10行，然後可憐的服務員就定時的移動腳步從第一排，到第二排，第…10排。輪詢問要點什麼。

經過一陣子後，店長看一看… 馬的，效果很差，於是就觀察，怎麼與他之前想的不一樣呢?

服務員在第一排問:「先生請問點什麼?」
先生 : 「………我看一下。」
服務員在第二排問:「先生請問點什麼?」
先生 : 「………我看一下。」
服務員在第三排問:「先生請問點什麼?」
先生 : 「………我看一下。」
服務員在第四排問:「先生請問點什麼?」
先生 : 「………我點1號餐。」
服務員在第四排問:「那飲料呢?」
先生 : 「………嗯? 熱的好? 還是…… 我想想…」
服務員在第五排問:「先生請問點什麼?」
先生 : 「………我看一下。」

‧‧‧‧‧
‧‧‧‧‧

服務員在第十排問:「先生請問點什麼?」
先生 : 「我要2號餐」
服務員在第十排問:「飲料呢?」
先生 : 「可樂」
服務員在第十排問:「要不要變大杯?」
先生 : 「……… 我想一下…」

服務員在第一排問:「先生想好了沒? 要點什麼」
先生 : 「………很難決定…讓我再看一下」
服務員:「#$#)dfe%」 (os 有這麼難嗎? 想那麼久…)

服務員在第二排問:「先生想好了沒? 要點什麼」






店長發現，小姐跑了十排，問了十人，結果一個餐點都沒完成。原來都是「他馬的，一堆事情沒想好、」造成小姐疲於奔命!

店長於是改了策略: 下令，櫃台只能有一排。 服務員先生: 「……我想想…」
服務員:「挖鼻孔等他…」
服務員:「想好了沒?」
先生:「喔，那就1號餐」
服務員: 「飲料呢?… (繼續挖鼻孔等)」
先生: 「可樂，不要加大。也不要加購。順便給我ketchup。」
服務員: 「先生，你怎麼突然變好快? 」
先生: 「因為你在挖鼻孔，我要快點結束…」

換第二位客戶。
服務員:「先生請問要點什麼?」

換第三位客人。
服務員:「先生請問要拿什麼?」

先生 : 「要」

就在這時候，第四位客人以後的所有客人開始不爽，「我都想好點什麼了，怎麼他馬的那麼慢，我餓死了啦! …xxx」


店長於是又覺得… 我看，這樣好了，就開個 「 馬的，怎麼只有4個櫃台，我們早就想好，要立刻點，她還在那裡跑來跑去的… 慢死了啦!」


這故事告訴我們，事情的真象就是:

1/「 閒置很久才要求一次，會殺死人!」。
2/「如果請求是一直來的，都不閒置，那就該讓他們一起上才快!」


連線數多不是問題，甚至多才會讓效能好。但閒置很久的連線，只會讓系統瞎忙。如果閒置久且數量多，那只有罵fuxx!







希望有多一點人會用心的把故事看完並思考之。畢竟看似小故事，其實是經過無數思維後的結果。此外，這也是 socket 阻塞，多線等同樣的問題。

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

編輯記錄

 附上與 datasnap 無關的一個 蕭沖心法。  給有緣人，不花時間再多做解釋!

回 ruru 的留言:

1/ 關於指出 com 元件使用datansap的情形。我原本想修正之前的章，加入註解。但那篇很可能太長，無論如何都不給修正。只好重貼於此:

!first available remote data module in the pool. If there is no available remote data module, it creates a new one (up to a maximum number that you specify)。

另 cb 6 書的另一個說法:
Object pooling gives you the ability to set a maximum for the number of instances of the remote data module inside the DataSnap server application. Whenever a client request is received, the DataSnap server checks to see free remote data module exists in the pool. If not, it creates a remote data module instance (but never more than the specified maximum number of remote data module instances) or raises an exception with the message Server too busy.

所以應該是指 : 「當連線來的時候，會去找第一個可用的instance來用」。我想會強調「第一個」應該是說它的實作並沒有用 Round-Robin 等一些演算法分配，而是找到可用的，就馬上用它，就算上一次還是它。

4/ 不過僅管 http pooling 可以把 RDM 留於池中，但照我的研究與看法，它不能夠對 db connection 部份做特別的pooling。換句話說，若每個instances的db conn 都是open的，那就會一直保持open。下個呼叫用它時，它依然是open的(除非上回的那個讓它close了)。換句話說，http pooling設一個上限後，到頂時，user端叫用就會失敗。然而，com 的做法則真的會自動開開關關，它的行為一如 jason wong 的說法一樣，可以往上，但又可以保留一個固定值，參照他回我的最後面的部份。也就是說 com 是比較彈性的可高可低，也可保有最低水位。以上在 http pooling的部份說詞，主要來自官網的文件，因它沒特別強調可以db conn pooling。而com 則講了 object pooling，與 db conn pooling 二個。我不敢100%說我的說法是完全正確的，因為我沒去實驗。另 com 的db conn pooling功能其實是 db driver 完成的，李哥是用ado，官網說dbx也可以。但bde或新的firedac可能不行。

5/ 限制住 http 的pooling 數，雖可" 間接 "的控制住 db connections，但一但到設的頂，就會無法服務，跳出 server too busy。假始你沒有設定pooling，每個客戶連線請求會令RDM創出來，並且在客戶應用程式關閉時RDM會死亡。有沒有 pooling 只差在「省下 Client 再次建立及初始化 RDM 所需要的時間」，一如你所言! 進一步的推論出: 「這樣的pooling方式並不能使用 db connection 有效率的 pooling(多功)」於是它與一般二層架構上，20人就20個db連線沒什麼不同。」至於 clientdataset上如何去讓遠端的db connection開又關，關又開，其實我也不懂。你知道的，我多數是用ado，對它不熟。但 ado 二層是可以 開關、關開的，也就是它也可以不用一直保持20個連線。

6/ 一定要再拉回原主題，我們談到「三層解決二層多連線問題」這個議題，並不少人強調「多連線造成效能低」。這樣的結論，無非是強調「三層優於二層」。然而三層真的優於的，理當主要是「安全性」(不能直連它)，至於效能? 連線數問題? 應該不是「為何要三層」的理由。李哥在com 的書上，第十章左右，有下了一個結論，筆數一但超過1000?(我不想再翻，記憶是)筆後，三層會比二層差到極大。真實的例子:
delphi.ktop.com.tw/board.php
11萬筆，3 秒 對 5分鐘，也就是差了 100 倍。就算他的架構可以再改進，但可想而知還是會差很大吧! (網友pedro我見過，有機會可以再問他) 。

7/ 講後那麼多的連線問題，無非是要提出 : 你何時需要三層? 我依然看法是，「在意安全」為主，「需大量運算為中間層」，「想提供給不同平台的客戶端都能吃」。不然可以試一下， ms sql 二層，用戶程式直連入 sql server (經 internet下，開1433 等 port) 真的不會比較快?，且也可以選項性的、技巧性的斷線再連。 另外，李哥在com 最後一章提到有人問他用了三層的dataset後，他的quick report變超級慢，要如何pooling? 李哥說，怎麼pooling都改善不大，最後是要它寫 stored procedure，於是差了10多倍。我提這個是因為，我說 db 是第三層，但很多時候沒有發揮每一層的能力。比如 db 若不寫 stored procedure，就算是有一點小對不起二/三層架構。把一堆 dataset 拉到第一層然後再演算處理，不如在 db 上就演算差不多後，把結果拉回來。喔，上面算是題外話，突想到的。

8/ 最後，關於 dataset 的cache問題。我想主因是 tsqldataset 根本是一個 cursor 。它應該要叫 TSqlCursor 才符合他的真實本位。它只是一個指標，指向 db server上的某一筆，要的時候往下取一筆下來。伺服器若是沒連線， 指標不就 野 了。我天馬行空的想，若中間層用的是 adodataset (靜態)，並不要取用狀態相關的東西，那麼在 instance pooling 的情形下，該 dataset 是真的有筆數的，下一個user連入並用這個instance的時候，理當不需再向 sql server 要資料! 因為 adodataset裡就有資料。這就有 cache的作用。不過… 當然… 極不完美。因為不同 instance下的 ado dataset 內容可能不一樣。這些東西除非自己實作 (就是我說的改裝之類的)。算了，煩又不易。


我說的「改裝」就是說，若照原廠的使用方式會有不少的缺點。若能夠修改源碼，或是自己加入不少的東西補強，就算是改裝。一如玩具手槍有機會改成土制手槍… 但前題是，玩具手槍本身就很接近真實的手槍，總不能是塑膠玩具手槍然後試著要改成真實手槍吧?


回完這篇，下回要進入 dcom 的解說。同時間，再次強調，關於 datasnap 我是學理為主，可以說沒有實作(一二次不算)，還是期待 ruru 發表所有他的經驗與實戰。我的文章僅 參考、愉樂 就可以! ^ ^


===================引 用 GrandRURU 文 章===================
自訂方法！嘿嘿，DataSnap02 就已經出現囉！但我不明白蕭大所提的「改裝」之意？

就像 Sryang 大說的，要保留 TDataSet 等物件的重複使用，在 DataSnap 下，是無法採用的。
重複使用 DataSet，那一堆 Client 該如何更新？再來找 TDataSet Post？這……

DataSnap 頂多只能做到保留 Remote DataModule Instance，省下 Client 再次建立及初始化 RDM 所需要的時間。。

Object pooling 章節中所提到的，在 Delphi 和 C Builder 是以不一樣的方式實做，以 Delphi 來說：
可參考：三層應用 webconnection與httpsrvr.dll與IIS的有關的問題

再看 C Builder........... 只能說 CB 真的是小三的孩子，連實作都很硬。

再談 Cache 的結論：RDM HttpSrvr.dll TWebConnection 才能夠享受 Object pooling 的效果。

再到 Doc 裡查了一下，發現 RegisterPooled 開放的連接池，僅保留第一個 Instance ，後面的參數是設定 Client 連線數的上限。
和 COM Object Pooling 還是不太一樣。

又， Sryang 大所說「很貴的連線數閒置浪費」的問題，係指在中間層可設定同時連線的上限(剛好 RegisterPooled 就是做這個工作)，這樣就可以規避 Client 數的版權費用！

DBMS 的 Cache，這個方法讚！

YA！可以看到蕭大來「庖丁解牛」了！這應該是 2015 年開始以來最精彩的時刻了！Ｕ

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

編輯記錄

要使用 COM+ ，用 RemoteDataModule 還是不方便的，應該用 MTSDataModule / TransactionalDataModule

以以前個人實做的記憶 (10 多年前了，那時還用的是 D5)，COM 有幾個好處

1. Object pooling，可以預先建立某個數量的物件等著被使用，若用戶數多於這個數量，則會再建立新的物件以應付需求，而最低會維持這個數量的物件，也可以設定物件消滅之前的閒置等待時間

2. 交易控制以及 two-phase commit，可以用 COM 設定來控制是否要參加交易，是否一定要起新的交易，以及交易隔離等級。而寫程式時就不用再自己控制資料庫交易了，只要記得成功了要呼叫 SetComplete，失敗了要呼叫 SetAbort。(SetComplete 與 SetAbort 是 MTSDataModule / TransactionalDataModule 提供的方法)

3. db connection pooling 確實是 database driver 提供的 (其實 ODBC 就內建這個功能)

以上是憑記憶寫的，不見得正確，望各位先進指導。

------
歡迎參訪 "腦殘賤貓的備忘錄" http://maolaoda.blogspot.com/

Http Pooling 在這邊更明確的說法，應是 RDMPool(Remote DataModule Pool)：

For HttpSrvr.dll 中關於 Object Pooling 這一部分
是我理解錯誤，「找出第一個可用的 RDM Instance」才是對的。

RegisterPooled，
表示 RDM 會在一開始就把 Instance 開到指定的數量，
不過設定大於 IIS 能夠接續的上限還是無用。

COM＋的 Object Pooling 有它自己的一套規則。

Database Pooling
從 .NET 是有個 .NET 應用程式集區這部分來看
在 Delphi 中應是依存在 AP 當中（可參閱Delphi DBX4 programming）

如果 AP 被消滅，則 Database Pooling 則同時消滅。
我認為它的存在感並不高。

Sryang，謝謝你的實戰確認。 你就是先進啦，沒什麼人敢指導你。

至於我上面貼RemoteDataModule 用在com 上，是因當時不知 com 上可以使用這樣的東西。誠然，事後了解後，理當是你說的TSDataModule / TransactionalDataModule。因他們也實作了 IAppServer 介面，故可與ClientDataSet 相通。 ；）

===================引 用 sryang 文 章===================
要使用 COM ，用 RemoteDataModule 還是不方便的，應該用 MTSDataModule / TransactionalDataModule

以以前個人實做的記憶 (10 多年前了，那時還用的是 D5)，COM 有幾個好處

1. Object pooling，可以預先建立某個數量的物件等著被使用，若用戶數多於這個數量，則會再建立新的物件以應付需求，而最低會維持這個數量的物件，也可以設定物件消滅之前的閒置等待時間

2. 交易控制以及 two-phase commit，可以用 COM 設定來控制是否要參加交易，是否一定要起新的交易，以及交易隔離等級。而寫程式時就不用再自己控制資料庫交易了，只要記得成功了要呼叫 SetComplete，失敗了要呼叫 SetAbort。(SetComplete 與 SetAbort 是 MTSDataModule / TransactionalDataModule 提供的方法)

3. db connection pooling 確實是 database driver 提供的 (其實 ODBC 就內建這個功能)

以上是憑記憶寫的，不見得正確，望各位先進指導。

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

 下面這張圖是從microsoft網站借來的。關於DCOM的方法傳遞。

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

 上篇我提到DataSanp09是基於JSON-RPC,並非REST。那你是否會說，

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

編輯記錄

 因新年過了，時間有限，講完了以上的技術後，快快的要來評論了!(目標是論三層架構，不討論 3 vs 2)

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

編輯記錄

 感覺我似乎還是要再補一些資料對大家可能更有一點幫助。所以本來想再一篇就要來結束的，還是再拖台一下…  反正我研究都研究了，不給大家參考藏身上也沒意思啦!

先來三張我自製的圖，是關於 DataSnap09 的三種精靈。僅管 ruru 也曾問過李維大哥，但我覺得那樣不夠清析，所以補上我的圖來說明。

「DataSnap Server 是提供一般應用程式形態的DataSnap伺機器,

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

大頂！大頂！

頂！那能不頂！
您的大作，從不敢不看，只是門外漢總是插不上嘴！

不過鑑於瀏覽器與 K.Top 相容問題，若有長篇，最好先打好存在 HD 上，
再貼到 K.Top，可減少被沒收的遺憾！

頂！
強烈要求置頂加精！

------
歡迎參訪 "腦殘賤貓的備忘錄" http://maolaoda.blogspot.com/

REST 指的是一種設計風格

DataSnap09 是基於JSON-RPC 協定，DataSnap09 整體實作的內容應算是 RESTful

但說它不是 REST 是有點牽強

因為它的確是採用 REST 的設計風格

以上

編輯記錄

純討論:

你說「DataSnap09 整體實作的內容應算是 RESTful」。

我想若我們有看法上的出入，那應該是 REST 架構是什麼?

至於RESTful這個詞，只是表達「符合REST架構所製定的限制條件」就算該系統或所提供之API是RESTful。

我想聽想你對REST的看法。如何是符合REST架構。 交流交流。然後我自己順便重新思維一下自己原來的觀點 。 :)


===================引 用 GrandRURU 文 章===================
REST 指的是一種設計風格

DataSnap09 是基於JSON-RPC 協定，DataSnap09 整體實作的內容應算是 RESTful

但說它不是 REST 是有點牽強

因為它的確是採用 REST 的設計風格

以上

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

Content-Length: 386

------


蕭沖
--All ideas are worthless unless implemented--

C++ Builder Delphi Taiwan G+ 社群
http://bit.ly/cbtaiwan

編輯記錄