2M上傳的話...看你的網頁的資料量,...
如果是平均一頁是500KBytes的話...
原則上可以上到50人同時上..而不會感到慢
因為不是所有人一直都在切換網頁的....
除非你是有放VIDEO...那就另當別論因為資料是一直流出的
若你的VIDEO的量很多的話那建議去租空間會比較好些..

漏掉了一位熱心的大哥....:o
資料量5百KB差不多... 不過裡面有個video....
應該會使用串流....
以這樣來看... 假設有50位user同時上線...
不曉得需要多少頻寛... 才能讓user順暢的觀看video...
如果無法作到頻寛的整合...
目前還有考慮另一個作法... 就是把web跟video作分流...
web連接db的部份用一條線路... video的部份用另一條線路...
這樣子作起來效率不曉得是不是會比較好... ?

贊助商連結

直接拉進來..!! 應該不便宜吧..... @@a
小公司.. 預算有限... ORZ
朋友寄來一帖.... 似乎是個可行方案...
不曉得這東東對多wan對外的web server有沒整合的作用... :Q

http://www.dombox.com.tw/memo/index_main_show.asp?menu_id=4_28&menu3_id=28


基本上任何的併頻裝置對網站都是沒有用的=>
因為單一對外的線路速度固定
所以外面連進來的時候一個ip就只能固定一個速度
例如我申請10M/2M X2
加上併頻器
區網內對外20M/4M 沒錯
但是外面連近來卻是
10M/2M 2XX.XXX.XXX.1
10M/2M 2xx.xxx.xxx.2
ip是不能合體的＝ ＝:|||:

基本上任何的併頻裝置對網站都是沒有用的=>
因為單一對外的線路速度固定
所以外面連進來的時候一個ip就只能固定一個速度
例如我申請10M/2M X2
加上併頻器
區網內對外20M/4M 沒錯
但是外面連近來卻是
10M/2M 2XX.XXX.XXX.1
10M/2M 2xx.xxx.xxx.2
ip是不能合體的＝ ＝:|||:

ip不能合體是一定的...
不過它似乎能在user要連進來的時候判斷哪條線路比較快...
而自動把user導入那條線路... 可以作到平衡線路負載的作用?!
據我所知... 好像是利用DNS的方式...
ex: 現有線路A 10M/2M 線路B 10M/2M
現有5個USER從 A連進來... 3個USER從B連進來...
當一個新USER要連進來的時候... 系統會自動幫其導向B線路....

補充一下... 您所提到的應該叫outbound balance
另外有一種inbound balance的功能...
不曉得是不是我說的這樣..
這我就不太瞭了... so.. 貼出來大家研究研究~~~

補充一下... 您所提到的應該叫outbound balance
另外有一種inbound balance的功能...
不曉得是不是我說的這樣..
這我就不太瞭了... so.. 貼出來大家研究研究~~~
還是申請大一點的水管比較實在...:|||:

頻寬合併器這東西原理
有點像flashget這類多點下載軟體
也就是開兩個或以上的連接(看你有合併幾條)同時下載資料
就可以達到下載合併的效果
用來架站的話..吃的是上傳
使用這類的設備..就沒辦法達到流量分散了...

如果要做到網路"容錯"
你得用那種貴到靠爸的"F"TTB:jump2:
ISP就會幫您建制多路由備援:)

如果大大只要做到流量分散而不需要容錯的話
PS: 意思就是其中一條網路掛了之後整個掛掉
只要再DNS新增兩個或以上的A紀錄就可以了


要達到"伺服器"流量分散與容錯(非網路)
如果是windows server的話..您可以使用NLB叢集
PS: 當然..一最少得要兩台伺服器才能做NLB叢集
設定還蠻簡單的,看微軟的教學文件就好摟
這樣就算有一台伺服器當掉,也不會影響到服務:)


如果是要租國外虛擬主機
找一家信譽良好的虛擬主機商
其實絕對比用VDSL架設要穩定:)
您可以考慮看看

原來是這樣啊... 聽說用dns的方式可以作到分流?

昨天打去台固.. 小姐竟然跟我說他們家沒有ftth光纖的產品?昏倒~~

不曉得大哥是架串流伺服器嗎?
1M-> 1024kbps /8 =128KB
128KB/8 = 16KB
16KB再打個八折.. 一個人只剩2KB的流量 ?

不好意思~ 小弟對這方面不太懂.. 還請前輩指教~~ 感謝...
這是買載的狀況才會發生的,一般而言僅僅架設網頁.FTP及MAIL,除非你公司很大.瀏覽人數很多,不然頻寬需求應該不大,即使架串流影音伺服器,也要看有沒有人會去使用吧,如果很少,那流量也很有限
至於實際上會是怎樣,以我的想法是先確認頻寬預算,然後想好修正配套,先以目前的方式使用,同時架個MRTG來了解實際使用量,如果真的頻寬不足,再增加頻寬吧
反正我是覺得先用目前已知的流量去預估,當預估值不足時再增加還來得及,頻寬反正是用租而且可以增加的,又不是買硬體不合適就全部完蛋