# Web 與 Database 在一起 把 Web 或 Database 弄在同一部機器這樣的方式，通常是用在程式開發的「本地測試機」中，或者通常不會`同時`拿來服務太多的人的應用（共同上線人數），像是一般基本的公司形象網站、個人介紹頁...等等不會有太多人同時存取的資料懷鏡時才會使用這樣的架構。 除了基本的 Apache（Nginx）及 MySQL（Postgres），視情況需要設置會把其他的服務也放在同一台機器，像是 Memcached、Redis、Node.js。 **_架構圖：_**  ### 使用時機 ### 同時上線人數約 10 ~ 15 人左右 **_人數為 KeJyun 過去經驗大概估算的人數，沒有經過實際測試僅參考用_** 當一台機器需要乘載多種服務時，同樣的主機資源要做很多事情，當然處理的效率通常都比較低 以飲料店來當例子，1 個服務生可以同時服務 3 位客人（主機同時有 3 個人發出請求），同時替客人做點餐結帳、做飲料的工作，但是當客人越來越多時來到 15 人的時候，因為人的能力有限（主機的效能有限），所以後面很多人就需要排隊等前面幾位客人拿到飲料後才能繼續服務，所以就需要等待排隊（主機回應時間拉長），所以要看自己的經濟規模（同時乘載規模）去聘請適當人數的員工（規劃使用不同的主機架構） > 同時上線非每日上限，同日上線指的是同一時先有多個人同時跟伺服器要資源 ### 服務的可用度不需要太高 大部份的使用者可能最高能夠忍受等待[一貶眼的時間](http://news.networkmagazine.com.tw/news/2012/03/02/38107/)（約 250 毫秒 = 0.25 秒），但是這個標準是在產品一秒鐘幾十萬上下時才需要達到的可用度標準（像是股票交易、電子商務網站、社群網站...等等），一般只是測試用或是形象的網站不需要那麼高的可用度，能夠在 1 ~ 2 秒內回應都是在可接受的範圍（當然不能太久超過 4、5 秒以上，使用者會以為網站掛掉了沒有回應） ### 資料有做異地備援 資料可以說是整個企業的資產及生命，當資料自己有做異地備援的話，就可以用這樣的方式，不然主機太操很容易掛掉（就像人一樣加班太久沒休息，就很容易生病），裡面的資料可能會因為沒辦法救回，所以若是有做資料備份，不怕資料不見的狀況下再去用這樣的架構去做服務。 ### 參考資料 - [你願意花多久等待網站回應？ 一貶眼都嫌太久了](http://news.networkmagazine.com.tw/news/2012/03/02/38107/) - [瞭解網站速度 - Analytics (分析) 說明](https://support.google.com/analytics/answer/2383341?hl=zh-Hant)