個人積分：4677分
文章編號：41097941
個人積分：11分
文章編號：41100618
個人積分：129分
文章編號：41102747
個人積分：0分
文章編號：41105488
個人積分：5分
文章編號：41105722
www.ubnt.com
UniFi企業無線網路-AP成長無限制！
http://www.bnext.com.tw/article/view/cid/108/id/25449
個人積分：440分
文章編號：41106386
ewiz wrote:
UBNTwww.ub...(恕刪)
unfi AP僅能算是單純的thin AP solution...
好處是沒有特定的依賴AC...
但是中央管理也會比較麻煩...
一個AP+AC solution..
可能使用某種tunnel將AC與AP進行連接...
例如CAPWAP標準使用5246~5247, udp通訊建立tunnel...
為了保證tunnel的安全性, 通常會進行加密..
data channel與control channel視情況而定是否加密...
這種solution對AC會有特定的依賴性..
不過好處就是中央管理比較方便...
一個案例的參考與學習:
http://www.mobile01.com/topicdetail.php?f=110&t=2960029
unifi solution是比較便宜的一種方案..
可以相容多種WiFi contoller...
不過我覺得他的探測工具不太好用..
而且reset button頗難用的..
個人積分：0分
文章編號：41110224
個人積分：66分
文章編號：41110781
a00110110 wrote:
請教各位大大：目前我...(恕刪)
在考慮各種 AP 解決辦法前，我建議先確認問題癥結在哪裡
通常 SQL 拋出來的資料應該不大，所以很有可能不是 AP 頻寬的問題
有下面幾點你可以再確認一下
1. SQL Server 是否有足夠的處理能力同時處理 40~60 個連線，這包含了 CPU、記憶體的考量。這是很常見的問題，應該優先確認。
2. 上面的延伸，資料庫的架構是否有優化
3. 使用者的連到 SQL 的 client 程式是如何處理的，有可能使用者沒有在處理，但是程式還在背景一直的跟 SQL 連線
4. SQL server 連出來的頻寬是否足夠
5. 內部網路的架構是否洽當，如果不洽當，有可能造成封包掉落，client 就一直的在重新發送封包
6. 是否有其他人同時間在佔用大量的頻寬
如果以上幾點都確認無誤，才有可能是 AP 的問題
個人積分：1786分
文章編號：41111846
個人積分：38分
文章編號：41112137
