搜主意工作室

提昇主機效能的關鍵因素

架設網路主機時，如果調配的方式錯誤，很容易造成效率不佳、穩定性下降，甚至減短壽命。那麼，有那些因素值得注意呢？

CPU
目前越來越多 CPU 已經採多核設計，也就是一顆可抵好幾顆。所以對於運算需求較高的主機而言，選擇多核的 CPU 是無庸置疑的。但若是模擬出來的假多核，如 intel 的 hyper threat 技術，就不見得有多大的實質助益。
RAM
記憶體方面也有這樣的趨勢，由原本的單一通道，提昇到雙通道，甚至三通道。這就像高速公路的車道，數量越多，車流的容許量越大。對於資料量大的主機，就必須特別注意這點，像是資料庫很大，或影音系統。
硬碟
現在硬碟的容量越來越大，已經有單顆 3T 的產品問市了。然而，讀取的速度雖然也跟著加快，但最關鍵的寫入速度還是不盡理想，而成為最大的瓶頸。為了提昇硬碟的效率，多數人是採用 RAID、SAN 或 NAS 來處理。後二者要花的錢很多，在這裡暫不討論。但就 RAID 而言，並不是架了 RAID 就會變快，例如是架 RAID 0(合併)和 RAID 1(鏡射) 來說，寫入的動作並沒有被分擔掉，所以有架沒架都一樣慢。
那麼，可以怎麼作呢？
筆者的作法是用二顆硬碟，以主從的概念來使用。例如要進行系統壓縮備份時，由 A 備份到 B，那麼一讀一寫，速度會快很多。這樣作還有一個好處，就是硬碟磁區的混亂程度會最低。因為在單顆硬碟上作備份時，會把前方讀寫速度較快的空間佔掉，而造成後續資料被寫入速度較慢的後段磁區。即使你把這些前方的大檔刪掉，後方的檔案也不會被移到前方。這表示硬碟讀取頭就必須有大幅度的擺盪才能讀到資料，這都會影響到效率。
網路卡
現在雖然已經進步到 Gigabit 的網卡，但是如果硬碟讀取速度不夠，還是會受限。
另外，當系統在進行大量資料傳輸時，網卡的頻寬還是可能被佔滿，而造成不同伺服器的延遲問題。
針對這部份的作法是採用雙網卡，甚至多網卡的作法，再依實際需求來規劃網卡的用法。
例如雙網卡的狀態，可以一張網卡對外，另一張對內供內網使用，這樣就可以避免內外網搶頻寬的現象發生。
主從式主機架構
也就是大家常聽到的 n-Tier 架構，它的概念也大同小異，就是簡單四個字：分工合作。
目前來講，當網站越長越大之後，可以先考慮架設 CDN(Content Delivery Network)主機來負責網站檔案的傳輸，這些檔案通常變動性較低，但讀取頻率極高。
等需求再大一些，就可以考慮架設專屬的資料庫伺服器，因為資料庫是整個系統的核心不能損?，獨立出來將有助於系統的穩定性，資源調配上也較明確。
之後，就可以考慮架設 AP 伺服器，讓多台主機來處理使用者的需求，再結合 Load balance 的設定，把需求分配給不同的 AP 伺服器處理。概念上可以看成大賣場的結帳櫃台，人多時就全開，人少時就只保留部份櫃台即可。
雲端系統
國外的 Amazon 和 Google 等業者都有提供系統龐大、收費低廉的雲端系統可供租用，當需求大到無法自行解決時，雲端系統也是值得考慮的選項之一。但在使用上，還是要評估系統的距離，遠在天邊的網路系統往往不比隔壁的主機來得快。

總結來說，效能的瓶項往往來自通道數量和傳輸方?。盡可能增加通道量，控制行進方式，就能提高系統運作效能。

CSS 的洋蔥式設計概念

應用 CSS 來設計網頁時，最常面臨的問題就是如何用最簡單的語法把畫面包得美美的。它可能是為了按鍵的效果、區塊的底圖等等....

這時候，要銘記在心的就是洋蔥式設計法。

利用以下的作法來達成設計上的目的，

這時候，你只要在 CSS 裡，作這樣的設定

.onion_skin { margin:0; padding:0; }
.onion_core { margin:10px; }
.level0 { background:url('中間底圖') top center repeat; }
.level1 { background:url('上方底圖') top center no-repeat; }
.level2 { background:url('下方底圖') bottom center no-repeat; }

這樣就能輕鬆作出很多樣化的漸層底圖區塊，然後只要把內容放在 div.onion_core 裡面就好了。

另外，也不是只能用 div，實作上也常常利用 span, font, a 這些指令來作選單底圖。例如：

<ul class="menu">
   <li><span><a href="">....</a></span></li>
   <li><span><a href="">....</a></span></li>
   <li><span><a href="">....</a></span></li>
   <li><span><a href="">....</a></span></li>
</ul>

這時的 CSS 寫法是

ul.menu { list-style:none; }
ul.menu li { float:left; width:auto; }
ul.menu li span { display:block; margin:10px; background:url('左側底圖') left center no-repeat; }
ul.menu li a { display:block; padding:10px; background:url('右側底圖') right center no-repeat; line-height:32px; }
ul.menu li.on span { background:url('新的左側底圖') left center no-repeat; }
ul.menu li.on a { background:url('新的右側底圖') right center no-repeat; }

再搭配 jQuery 作如下的設定

$(document).ready(function(){
   $('ul.menu li').hover(
   function(){ $(this).addClass('on') ; },
   function(){ $(this).removeClass('on') ; }
   );
}) ;

這樣就可以作出橫列式的選單效果，並且有滑鼠 hover 的效果了。

網路 API 盛行的影響

過去作網站都是將重心放在自己的網站上，但在 WEB 2.0 的概念之下，每個網站無不費盡心思開發 API，讓廣大的使用者協助找出平台設計者所忽略的應用。

這看來並沒有什麼不對，但是卻不能不留意這個趨勢所產生的影響。

舉例來說，現在網路主要的資源來源包括：傳統媒體的新聞內容、傳統作者發表的文章、網友自主發表的文章。

原本這些內容只能在這些媒體網站、部落格平台上出現。

但是，透過許許多多的 API (例如 Google Blogger API)，就開始有人以程式自動從搜尋引擎搜集各種網頁內容，然後將它自動轉換成部落格的文章。

或許你會想這樣作有什麼用？

關鍵就是網路廣告。

這些內容多少有一定的讀者，這些流量就能轉換成廣告曝光量，變成一定的收益。

這在網路的生態中並不算違法，轉載者只要有註明出處，一般來說新聞媒體也不會找麻煩。

那麼，這表示什麼結果呢？

也就是所有新聞一經發佈，它的新聞價值會在最短的時間內被消耗殆盡。過去，是網友會慢慢手動轉載、引用，但現在，是程式透過 API 以驚人的速度進行重製。

這樣的情況下，將會造成內容原創者越來越難從內容直接獲利，只能得到知名度。促使內容原創者會傾向以置入性行銷的模式，加快從內容直接獲利的速度。逐漸讓內容變得越來越商業化，失去內容原有的深度，也失去讀者的信任。

簡言之，網路文化的黑暗年代即將來臨。而這，竟然來自人們自以為的進步─API。

雲端概念下的網站經營策略

雲端應用近年來已經炒得非常火熱，但是真正派上用場的情況卻不多見。

對於租用實體主機／虛擬主機的網路業者而言，最大的成本來自於使用的硬碟空間和網路流量。

為了提高網站運作品質，往往得租用比實際需求更高的流量，才不致於發生塞車的現象。

為了提高內容的精緻度，往往得用較多的碟碟空間，才不會造成過度壓縮而產生失真的現象。

對這些情況來說，最關鍵的莫過於影音、圖檔的資源需求。

現在大家都知道要把影片傳到 YouTube 才會省錢省事，那麼圖片呢？

我的建議是放到 Google 的 PICASA 相簿去。

因為它有1G的免費空間，就算昇級到20G，也不過每年5塊美金的費用。請注意，這包含了空間和流量。

再者，像時下流行的 WordPress 等部落格也都支援 PICASA 外掛，讓網站經營者得以在網站內容中嵌入放在 PICASA 的照片／相簿。

如此一來就可以讓使用者維持正常的網站瀏覽習慣，但卻又可以把最耗費資源的部份丟在雲端上。

就能夠保有網站原有的競爭力，節省無謂的資源浪費。

實際案例：Showgirl 名模網，早期也是把 Showgirl 照片放在網站上，一旦人潮爆增時，頻寬就出現塞車現象。現在則是把最吃頻寬的照片轉移到 PICASA 網站，節省了九成以上的頻寬，卻還沒花到任何一毛錢。

Google PICASA 相簿

利用 memcache 來加速網頁程式的運作實測

優化網站程式效率的作法很多，包括資料庫的充份正規化、快取技術、多層次主從架構等等，所有的方法為的都是減少不必要的運算和用最快的方式取得資料。

本文要談的是 memcache 這種作法，它是在主機上切出一塊記憶體作為公共儲存的空間。透過函示庫可以讓 php 這類的網頁程式將數值寫入記憶體備用。

那麼，實際的效能如何呢？

我以一個約二萬筆的資料表來作了一點試驗，得到以下數據：

開始測試 : 2010-03-27 22:24:57 0.14270200
鍵值查詢 : 2010-03-27 22:24:57 0.14330700   0.00060
欄位查詢 : 2010-03-27 22:24:57 0.16809800   0.02479
記憶快取 : 2010-03-27 22:24:57 0.16884600   0.00075
記憶鍵值 : 2010-03-27 22:24:57 0.16886300   0.00017

由以上的數據可以看出，以資料表的鍵值向 MySQL 送出的查詢非常快速，但用一般的欄位去查詢就非常緩慢，差了將近 41 倍，而透過一般欄位值 memcache 取得相同的資料的時間則和使用鍵值查詢的速度相仿，但使用鍵值直接向 memcache 取得資料則比 MySQL 查詢省了 2/3 的時間。

由此可知，在講究執行效率的平台上，千萬要避免對 MySQL 送出一般欄位的查詢；對於能直接或間接以鍵值取得的資料，則可以考慮將它預存在 memcache 中備查。如此就能讓程式效率發揮到最大！