→ xurza: 先做好遠端桌面讓使用者撐著用,但最終還是必須要回到工作站 01/06 14:41
→ chang0206: XenAPP / Terminal Service 01/06 15:45
推 chang0206: 總的流量看起來不大 MPLS VPN或許可以解 01/06 15:49
→ chang0206: 不過這東西沒在給測試的... 01/06 15:49
→ asdfghjklasd: 這問題又不難.而且這是已經知道的問題啊XDDD 01/06 17:09
→ asdfghjklasd: 你們連跑POS都會有問題 01/06 17:10
→ johnten: 多年前我也曾經跟你一樣天真,以為ap可以擺在遠地wan端 01/06 18:19
→ johnten: 只可惜就算我兩點VPN速度再怎麼快,AP連到DB就是龜 01/06 18:20
→ OSDBNetwork: 在 192.1.3.X 架設一台 "多人遠端桌面連線" 就好了. 01/06 18:20
→ johnten: 後來才知道TS才是正解 01/06 18:21
→ johnten: 你問到重點了 跨國企業怎麼辦 上叢集吧.. 01/06 18:22
→ appledavid: TS or chtml 01/06 19:52
推 chang0206: 請問CHTML是什麼技術? 01/06 20:12
→ deadwood: 對DB的效能而言,WAN的延遲應該才是最大瓶頸,自己算算 01/06 21:41
→ deadwood: 兩者延遲差了幾倍,就不難理解為何會差這麼多 01/06 21:42
→ konkonchou: 首先報表程式能不能改,有沒有辦法知道PL/SQL指令下的 01/06 21:59
→ konkonchou: 方式 01/06 21:59
→ konkonchou: 有的 PG 寫的程式本地端開發,SQL不會寫,也許一支報 01/06 22:04
→ konkonchou: 表一萬筆資料執行了10001次,一次1ms 結果花10s 無感 01/06 22:04
→ konkonchou: ,放到異地執行假設16ms就160s以上就差很多 01/06 22:04
→ konkonchou: 也許拉好View或串好table結果直接跑出來, 串不出來就 01/06 22:08
→ konkonchou: 學應用cursor去跑就行了 01/06 22:08
→ konkonchou: 若無法看報表程式,或許減少報表資料量就可以驗證是否 01/06 22:10
→ konkonchou: 這原因造成 01/06 22:10
→ dennisxkimo: vpn環境 ping 資料庫ip -l 1472 -f出切割訊息 會很慢 01/06 22:26
→ dennisxkimo: 但是不管頻寬多高 vpn環境下 user最後回歸TS 01/06 22:28
→ kobedisel: 樓上已有正解 network letency 01/07 00:11
→ dou0228: 報表在遠端做好,ts連進去看才是正解。 01/11 15:06
→ asdfghjklasd: 當每家都不同業主時,你看看TS主機誰會出....XDDDD 01/11 19:00