以下引述自原文內容。
會有這些想法，是因為在新創公司工作，軟體開發人員同時必須身兼系統管理員。
兩條簡單的規則，避免過度的複雜化
- 避免寫一支程式同時取用兩個以上的資料來源
最佳情況就是讓程式跟大多數Unix指令工具一樣，一個程式負責一個input產生一個output。 - Linux可以做的事，就不要傻傻地自己去做
除非xargs指令解決不了問題，否則就不要去用Hadoop MapReduce (一種新興雲端概念的框架)
不要實作自己的鎖定服務，除非Linux的檔案鎖定沒有作用
盡量用ImageMagick處理影像檔，除非必要否則別去用PIL之類的影像處理函式庫
現代的Linux發行版已經解決大量的問題，你需要做的只是去找方法
(譯註：如果能解決問題的工具不是OpenSource軟體，身為台灣人，你可以選擇用盜版、也可以自己重新實作，在良心及肝功能之間作抉擇。所幸大部分我所需的功能都有OpenSource替代方案。拿xargs跟Hadoop MapReduce相比有些誇張，換個方式說，能用SQLite/MySQL滿足的需求，就不要傻傻地用SQL Server或Oracle Database搞死公司自己。ImageMagick是很方便的命令列影像處理軟體，最常用的是它的convert轉檔指令，做個縮圖轉格式啥的靠它就能搞定，通常沒必要去用緩慢又要自己handle錯誤的函式庫，但使用ImageMagick要注意安全性問題)
當你真的需要時才去做平行處理，而不是光想要就去做
一台機器處理得不夠快，無法滿足需要時，應該去分析為什麼跑得這麼慢，而不是急著去做更複雜的平行處理。
如何照料一個行程
在一個行程掛點(crash)時，要讓它可以自動重新執行，有Upstart工具可以用，設定檔的範例如下。
respawn limit 10 600
exec python /path/to/my/program.py
NoSQL is NotWorthIt
Ted嘗試將Redis用在非主要任務的系統，那些應用程式的資料如果流失並不是什麼大不了的事。大多時候可以運作，但問題發生時，Redis伺服器hang住，socket連線接通後卻沒有回應，重新啟動伺服器花了45分鐘才恢復。也許其他NoSQL資料庫情況會好一些，但是問題點還是一樣，為什麼好端端的PostgreSQL同樣可以完成工作不用，而非要去玩新奇卻必須冒險的東西。
Event Loops are Just Okay
Wikipedia上提供的一段Event Loops程式碼示範。
function main
initialize()
while message != quit
message := get_next_message()
process_message(message)
end while
end function簡單說，就是每次收到任務時才開始做事，而且必須做完一件才接受下一個任務。
最危險的是程式設計師搞不清楚自己做了什麼事。在event-loops及thread之間抉擇最佳的方式，必須視I/O bound等軟硬體的特性，有時也可以混著用。
Hardware Matters
雲端運算的強大似乎很有吸引力，當它變得高效能又可靠時，世界各地的不同電腦將成為你程式執行的實體機器。這裡不是在談論Extra Large EC2的容量超大，而是一個系統效能特徵為何。
舉例來說，對輸出資料量龐大的應用程式，你會希望呼叫 fsync (通常是用在實際將資料寫入磁碟) 時盡可能早點結束，fsync是作業系統提供的函式，它你的程式無法控制的黑盒子。當這是一個瓶頸時，必須靠的是硬體升級，裝一個內建電池的RAID控制器，這樣 fsync 呼叫幾乎可以立即完成，因為RAID控制器的記憶體可以先保存資料，即使遇到電源失效，它也能保證資料最後會被寫入。
對於必須讀取大量資料的應用程式，當對檔案的隨機存取動作頻繁時，花多點錢裝上效能不可思議的固態硬碟(SSD)，就能夠解決磁碟讀取效能的問題(但是對循序讀取的程式來說差異就沒那麼大)。
硬體開銷是資金的好去處之一。要解決效能的問題，花錢升級硬體比起重寫程式有效率多了。當你用普通的機器執行程式，就不該期望它能跑出不普通的效能。
沒有留言:
張貼留言