雜志的官方blog RSS: http://blog.csdn.Net/emag_cpp/Rss.ASPx
文章:重負載Telnet BBS 系統優化和維護經驗談
一:IO優化
a) 盡量使用shm 等IPC 手段而不是文件
這一點在我們的系統裡核心部分有比較充分考慮的(用了一個G以上的共享內存)，用shm取代數據庫或文件。
甚至flock 這樣看起來不會造成太多IO 的同步操作都應該盡量避免，原因是flock 需要先open文件，而open 文件需要找到i 節點，因此會占用文件系統的inode 緩存空間，可能造成其他IO 操作的性能降低。在很多情況下面需要的只是一個跨進程的mutex，可以使用0/1 信號燈來實現
在我們的系統裡頻繁的使用了記錄鎖（用的是fcntl),從邏輯上講無法避免(必須實現讀寫鎖).是否對性能有所影響,目前沒有統計.pthread_rwlock系列函數是線程級的,不太適用.
b) 使用應用層緩存。
這一點有考慮.把數據完全或動態的從文件或數據庫加載到內存裡,在實時業務使用.實行中命中率還可以,但由於實現原因,面臨著一些數據同步問題.
c) 盡量減少關鍵IO 數據結構的大小
我們的系統實時任務部分雖然沒有頻繁的磁盤操作,但系統各模塊間傳遞的數據塊有一些臃余,原因是結構體設計主要考慮了通用性,使用了union或大數據緩沖定義
.
d) 避免在同一目錄下放過多文件或者使用合適的文件系統
暫時沒有這方面的問題.
e) 根據系統的訪問模式選擇適合的硬件配置和系統參數
這部分問題不大,用的是都是很強的機器並將系統內核參數調整得很充裕.
2: 內存使用優化
a) 盡量避免動態初始化常量，使用const 說明將變量和常量區分開來。
"動態初始化常量"的提法比較奇怪的說....不過一般來說在我們系統裡作為常量,都會被聲明為全局的,應該不會有所謂"動態初始化"的問題.
b) 減小內存的峰值使用，特別是堆棧中內存
文章中提到盡量少定義或malloc大塊的緩沖區,這一點是必須注意的.在我們的系統裡動辄定義或malloc(並初始化&free)上兆甚至幾兆,兩位數兆的地方都有.
c) 如有可能，盡量使用shm 來保證頁面一定會被多個進程共享。
這一點已經有充分考慮.
3: CPU 優化
a) 使用針對硬件優化的編譯器
推薦編譯時候針對特定CPU 指令集優化並且打開跨文件優化選項(-ipo)
對於編譯器和編譯過程目前的研究比較少,基本上只用了gcc的常用選項,而且是調試模式(-g)!!庫都是靜態連接,導致可執行文件龐大,加載緩慢.
b)用單獨進程來初始化和維護共享內容，避免出現競爭導致邏輯錯誤
在初始化共享內容時,有些環節在保護和互斥上作的還不夠.極端情況下容易出現問題.
c)序列化容易導致負載上升的行為
目前對這一點重視還不夠,除了技術因素,還有業務流瓶頸和沖突上的分析都不夠.
d) 盡量減少信號的使用
系統在一些環節上過度和不恰當的使用了信號,但目前正在逐步的盡量減少類似代碼.
e) 對於大范圍IO 讀取操作，使用mmap 調用
對於龐大的日記分析操作,可以考慮用mmap優化之.
使用mmap 操作比傳統的read 操作好處是減少了一次內核態到用戶態的拷貝。但並不適用於有寫入的情況，因為mmap 寫盤的時候是以頁為單位進行操作，頁中只要有一個字節被改寫，就要往磁盤上面寫整個頁面的數據，
另外的幾篇文章
<C10K 問題>: 比較全面的介紹了並發服務器的各種響應模式.比我之前寫的一篇服務器編程筆記強多了.
<從異步談起>:也是比較全面的介紹異步操作技巧的一篇文章,但重點是Windows平台上的overlapp操作.
<可變參數學習筆記>,對c/c++編程裡比較微妙的var_arg/var_list有比較好的討論研究,但我沒有嘗試其代碼.
csdn這批e_mag內容質量還比較不錯,值得經常看看.