由 helix84 - own work, based on [1], 公有領域, 連結
 |
開發多層應用程式時，第一關就是面對【多次連線】和【持續連線】的選擇，雖然網路一面倒向多次連線才是王道，但實際真的適合自己嗎？
環境
以下的環境提供你參考：
- 資料庫主機對外網路速度：6M 專線 / 100 MB ADSL。
- 客戶端必須使用 IE Proxy 過濾網站。
- 同時上線人數：250 人以下。
- 應用程式特性(1)：極短時間內會有大量 SQL 注入。(笑)
- 應用程式特性(2)：每個客戶端都會連到不同資料庫。
節錄網路上多次連線的優缺點
對於伺服器來說管理較為簡單，存在的連接都是有用的連接，不需要額外的控制手段。但如果客戶請求頻繁，將在 TCP 的建立和關閉操作上浪費較多時間和頻寬。
節錄網路上持續連線的優缺點
可以省去較多的 TCP 建立和關閉的操作，減少浪費，節約時間。對於頻繁請求資源的客戶端適合使用。
客戶端一般不會主動關閉連接，當 Client 與 Server 之間的連接一直不關閉，隨著客戶端連接越來越多，Server 會保持過多連接。
這和我們一般普遍認知的 100M / 1G 的區網不太一樣，這樣的頻寬認真說來蠻吃緊的，2-TIER 架構下就算是持久連接也快不起來，如果是你，你會怎麼選擇？
中間層架構
這樣的環境下若採用多層架構，並對傳輸過程進行壓縮傳輸，就能改善傳輸效率，在這裡又有兩個分歧。
一對多
一個資料庫連線給多個客戶端輪流使用。
多對多
多個資料庫連線給對應的客戶端使用，毎個客戶端皆有自己專屬的連線。
經過這樣的過程，可以知道【多對多】更佳適合使用環境，但究竟要使用多次連線還是持久連線？
已知多次連線和持久連線的差別在 Client 到 Middle Layer 的連線模式，那 Middle Layer 是否也要保存對資料庫的 Connection？
實作
有關實作的部份，可以參考"ebook【Delphi跨平台資料庫程式設計火速上手】電子書出版 (CHT)"一書。
效能
雖然 DataSnap REST 是基於 JSON RPC 傳輸，但 TCP 和 HTTP 兩者傳輸仍有其不同，TCP 以 Binrary Stream 傳輸；HTTP 則是以 String Stream 傳輸，實測單一客戶端的傳輸效能，就算是 HTTP ISAPI 有 IIS 加持，但 TCP 仍舊是明顯勝出。
突破防火牆能力
DataSnap HTTP 支援 ISAPI 發佈，同時也能做到持久連接，這個架構在突破防火牆的能力是最好的。
加密能力
DataSnap 自帶的 PC1 加密會將封包放大 6 倍，所以建議不使用。
總結
採用持久連接對於開發和低連線數的應用上還算不錯，在這裡向你推薦。
沒有留言:
張貼留言