近來公司redmine伺服器表現很糟糕，在16核，64gram的機器上，壓測結果竟然只有每秒5~7個請求，部分頁面乙個都出不來。
以下是我對redmine效能優化方案:
redmine伺服器效能問題排查與優化建議：
以下建議的方案是基於redmine執行期的log檔案中的render耗時、activerecord耗時，linux系統效能指標取樣與 mysql 效能指標取樣分析，以及redmine在不同web server下的benchmark而得：
一. 問題排查與定量分析
通過分析redmine執行期的log，對比mysql高峰時段的請求量與此時系統cpu、mem、disk、iowait等指標，以及我在本地的相同環境下的偽造併發量的效能測試結果，可以看出伺服器中高峰時段並未有效利用cpu與記憶體. 最主要的4個原因是：
1. rails框架過於笨重，執行效率低，
2. 乙個ruby程序只能利用單核cpu，其多執行緒受gil所控，多執行緒效率較低，無法有效利用多核cpu，因此在高峰時段只有passenger程序占用的幾個cpu滿載，其餘利用率基本為0。
3. 目前redmine的發布方式是apache+passenger， passenger沒有進過優化，只開啟了6個worker，而且只是程序級支援，這導致了iredmine伺服器的吞吐量非常低。
4. mysql的執行模式沒有進過優化配置，基本裸跑。
1.1 效能指標說明：
1. linux系統取樣指令碼：在~/performancelog/collectlog.sh中，或者看這篇
linux系統效能指標的採集部落格；
取樣結果在~/performancelog下，以日期命名的檔案中。
2. mysql的指標資料可以通過執行如下命令：
然後瀏覽器開啟：
可以檢視mysql的各項指標。
1.2 redmine伺服器的壓測、benchmark定量分析方法說明：偽造併發http請求，檢視每秒併發10個請求時，不同web server的效能表現。
針對不同web server的負載測試方法如下：
在量化效能時，本方案帶來的的效能提公升時，為了方便ab測試，建議關閉redmine**中csrf保護，並利用session，自動登陸，以保證測試的位址有sql操作，確保測試過程包含sql請求，方法如下：
取消csrf保護方法：
ab模擬併發測試步驟：
0. ./ctlscript.sh stop apache
2. chrome瀏覽器，開啟url， 檢視inspect tools, 複製cookies
3. 使用ab工具： ab -n 800 -c 16 -h 「cookie: key1=value1; key2=value2」
二：優化方案說明：
1. 併發量過大時反應慢的問題 #ok，使用multi-process * multi-thread的 web server
2. 資料庫讀寫效能過低 #ok，開啟mysql查詢快取等。
3. 使用非同步io庫em-synchrony，提公升io吞吐量。 #failed， 經測試，不穩定，介面版本有時不匹配，需3.1以上版的rails。
4. 使用rubinus or jruby 提公升執行效能 #failed，經測試jruby 記憶體損耗太大， rubinus有相容性問題。
5. 去除rails預設載入的非必需的middleware #rails預設載入20多個中介軟體，有些是無需的。
進過以上幾個步驟的優化調整，進過ab測試發現，吞吐量可以提公升2到3倍， 負載能力也有提公升，但沒有去測極限資料。
三：web伺服器優化建議：
建議使用多程序多執行緒版的puma替代多程序單執行緒passenger， 或者 任然使用passenger，但是配置成預設開啟14個worker，方便高峰時段留兩個cpu給mysql使用。 另外， 由於puma可以一定程度利用多執行緒來serve http請求，為了保證執行緒安全，需修改iredmine**：
新增config.threadsafe!到config/enviroment目錄下的production.rb檔案中
# enable multithread, and keep thread safe.
config.threadsafe!
1. puma的使用： 啟動14個工作程序*16個執行緒，提公升吞吐率。
2. 配置passenger方法：
配置檔案在：/redmine/apache2/conf/bitnami 目錄下，新增以下：
passengermaxpoolsize 14
四：mysql伺服器優化建議：
mysql的伺服器優化主要依賴mycheckpoint
採集的mysql效能指標視覺化之後的分析，以及mysqltuner.pl的調優建議。
1. 在mysql的配置檔案中開啟一下設定（以下有兩個變數設定後需要重啟mysql）：
threads_cached -> on
thread_cache_size = 64;
query_cache_size (>= 8m)
join_buffer_size (> 128.0k)
tmp_table_size (> 16m)
max_heap_table_size (> 16m)
thread_cache_size (start at 4)
table_open_cache (> 800)
innodb_buffer_pool_size (>= 371m)
另外還有： thread_concurrency = 32; (cpu*2)
關於mysql的使用者請求壓力情況，請檢視
五：rails優化建議： 刪除不需要的middleware
請聯合目前redmine外掛程式開發人員，根據當前rails的實際middleware使用情況進行篩選刪除。
config.middleware.delete "rack::lock"
config.middleware.delete 'rack::cache' # 整頁快取，似乎在redmine中沒有用上。
config.middleware.delete 'rack::runtime' # 記錄x-runtime（方便客戶端檢視執行時間）
config.middleware.delete 'actiondispatch::requestid' # 記錄x-request-id（方便檢視請求在群集中的哪台執行）
config.middleware.delete 'actiondispatch::remoteip' # ip spoofattack
config.middleware.delete 'actiondispatch::callbacks' # 在請求前後設定callback
config.middleware.delete 'actiondispatch::head' # 如果是head請求，按照get請求執行，但是不返回body
config.middleware.delete 'actiondispatch::beststandardssupport' # 設定x-ua-compatible, 在nginx上設定
等等。。
六： 去除production 模式下rails不需要的log 與 某些異常的修正。
1. 由於在production.log中發現了大段的debug模式才需要的log全部輸出到了log檔案中，耗時較長，建議刪除。
2. 某些url出現了 runexception. 建議修正， 或者在 middleware中去除名稱為：use actiondispatch::showexceptions
use actiondispatch::debugexceptions
七： 部分redmine外掛程式寫的比較糟糕，render耗時長達3000ms
1. linux系統效能定位與排查：
2. redmine的ab壓力測試方法：
3. mysql效能記錄與分析：
4. mysql優化工具：
5. linux io問題分析與排查：
6. mysql效能測試工具與方法：
Lustre效能優化方案
部落格公告 1 本部落格所有部落格文章搬遷至 部落格蟲 網路頻寬往往決定著lustre檔案系統的聚合頻寬。lustre是通過多個oss同時讀取資料來提高系統整體的讀寫效能，然而，如果網路傳輸的效能過低，則無法發揮lustre檔案系統的效能優勢。從以下幾點考慮網路頻寬對效能的影響 網路型別 tcp i...
Android效能優化方案
android效能優化的方案比較多，在開發過程中，主要考慮從以下幾個方面優化 1.布局優化 2.繪製優化 3.記憶體洩漏優化 4.響應速度優化 5.listview優化 6.bitmap優化 7.執行緒優化 接下來我們從這幾個方面為大家簡單介紹優化方案 大家肯定都知道android中有許多布局，比如...
前端效能優化方案
1 雪碧圖 css sprites 就是把多張圖合到一張圖裡面，然後通過css來分別取用。這樣就可以減少請求數量。2 合併多個指令碼和樣式表 3 合理設定快取 可以在下次訪問時減少部分請求，直接在快取中讀取。4 懶載入 lazy load 只載入可見的部分。先將img標籤中的src鏈結設為同一張 空...