其實這段時間大家也都知道，到了晚上尖峰時刻，討論區的速度真的是很慢。有人以為是頻寬的問題，其實並不是，證據很明顯，就是你只要是看一般的頁面，那麼下載的速度還是十分的迅速。
推就討論區緩慢的原因，除了人多之外，CPU 不快、硬碟不快、記憶體壅塞都是因素。而目前是網友 bryant 友情贊助我們主機，但想要對主機升級，這就不是我們該做的事情，不但逾越分寸，也會帶給人家困擾。
我曾經數度為了主機空間、頻寬等問題傷腦筋，也安裝了流量軟體來評估自己的網站到底會吃掉多少頻寬，一直無法找到一個平衡點來決定將來主機應該怎麼做。但就在昨天，我突然想到，何不把討論區與網站分開來？
網站本身提供的是文件說明、新聞、博物館，只使用一般 HTML 與 PHP。
而討論區另外使用一台主機，專跑 PHP & MySQL。
分開來是沒有什麼特別，但是，如果討論區是放在家裡呢？租用一條 1.5M/384K 的 ADSL，讓 upload 達到 384Kbps，這樣只針對討論區的話，應該足以應付目前的需要了，甚至將討論區中的表情圖案、title 等圖形全部外移到免費空間的網頁，這樣又可以再減少頻寬，使得送出的資料再減少。
而我可以盡力在家中把機器調校到比較高的效率，缺什麼就補什麼，當機了也不會有虛擬主機一起死所造成的不便與尷尬。
不知道大家對這樣的作法有什麼意見與想法？
討論區加速計畫
版主: DearHoney
-
realsync666
- 大師
- 文章: 79
- 註冊時間: 2001-04-10 08:00
-
Alan_Huang
- 大師
- 文章: 81
- 註冊時間: 2001-01-05 08:00
- 來自: 三重硬梆梆
- 聯繫:
放在學校這種作法，如果我今天還是在學學生，那還說得過去，但我都畢業兩年了.....
不過，學術網路很壅塞，真要放的話，我也是挑台大、交大、中興、成大、中山這些區域網路中心來取得「真正的」最大頻寬，但總之，這種偷渡在學校內的作法，我自己已經不打算採用。
剛才晚餐時，還在想這個問題，而現在想到稍微再更好一點的了，就是放在家裡的，只有「資料庫」。\r
MySQL 是以 IP 去連線的，我在家裡架設比較強的 MySQL 資料庫，讓網站的 PHP 來發出存取命令，家裡的 MySQL 就回傳結果，連討論區的畫面都不用送，這樣佔用的頻寬更低，就能確保 384Kbps 的上傳能力能夠很從容的應付，而我只要專心把 MySQL 資料庫的效能提高就好。
這樣的作法是在人數少時，整體表現勢必不如 MySQL 與 WEB server 在同一台機器上時的 response time。粗略猜測也許不管人多人少，這資料的一來一往大概要一秒，人少時，MySQL + WEB 同一台的，反應時間不到一秒，但是人多時，就像現在，超過 20 幾秒變成常有的事情，可是如果 MySQL 放在家裡且為強力的機器的話，人多大概也是一秒就完成工作，那就值得了。
網站經營到這樣的地步，自己不掏點錢，實在有點說不過去了。如何用最少的錢取得最大的效益，還真是夠傷腦筋的。
當然我會想辦法去賺點外快。我是不求這個網站能為我賺錢，但如果這個網站的收益能夠平衡網路頻寬費用，那就夠了。
不過，學術網路很壅塞，真要放的話，我也是挑台大、交大、中興、成大、中山這些區域網路中心來取得「真正的」最大頻寬，但總之，這種偷渡在學校內的作法，我自己已經不打算採用。
剛才晚餐時，還在想這個問題，而現在想到稍微再更好一點的了，就是放在家裡的，只有「資料庫」。\r
MySQL 是以 IP 去連線的，我在家裡架設比較強的 MySQL 資料庫，讓網站的 PHP 來發出存取命令，家裡的 MySQL 就回傳結果，連討論區的畫面都不用送，這樣佔用的頻寬更低，就能確保 384Kbps 的上傳能力能夠很從容的應付，而我只要專心把 MySQL 資料庫的效能提高就好。
這樣的作法是在人數少時，整體表現勢必不如 MySQL 與 WEB server 在同一台機器上時的 response time。粗略猜測也許不管人多人少，這資料的一來一往大概要一秒，人少時，MySQL + WEB 同一台的，反應時間不到一秒，但是人多時，就像現在，超過 20 幾秒變成常有的事情，可是如果 MySQL 放在家裡且為強力的機器的話，人多大概也是一秒就完成工作，那就值得了。
網站經營到這樣的地步，自己不掏點錢，實在有點說不過去了。如何用最少的錢取得最大的效益，還真是夠傷腦筋的。
當然我會想辦法去賺點外快。我是不求這個網站能為我賺錢，但如果這個網站的收益能夠平衡網路頻寬費用，那就夠了。
