cpu的運算速度發展迅速，最高峰平均每隔幾個月，速度就翻一倍，目前cpu的乙個時鐘週期已達到納秒級
近幾年cpu的發展趨勢不再是提高速度，而是並行化，包括支援多cpu多核，超執行緒和numa結構
原因是儲存裝置的速度發展相對滯後，單純提高cpu的運算速度已無法有效提高系統的效能
因此除少數計算密集型系統外，大部分系統的效能瓶頸往往在儲存裝置效能
relative latency
記憶體的讀寫效能是磁碟的10w倍，因此基於記憶體操作的redis的效能會顯著高於基於磁碟操作的資料庫
linux預設記憶體分配函式ptmalloc效能不佳，並且存在記憶體碎片率過高的問題（部分長週期記憶體會影響其他記憶體**）
redis封裝了zmalloc函式，如果linux安裝了tcmalloc，則使用tcmalloc，否則使用預設的jemalloc
zmalloc.c
blocking io要求1條執行緒支援1條連線，連線僅消耗少量記憶體，並不稀缺，但執行緒為稀缺資源，一台機器一般最多支援1000條執行緒左右，因此blocking io嚴重制約系統吞吐量
nonblocking io需要不斷check連線狀態，cpu消耗嚴重
io multiplexing支援1條執行緒監聽多條連線，不需要反覆check，當有連線傳送狀態變更時，返回連線集合
單執行緒處理所有io事件，由於redis的請求都是記憶體操作，效能很高，因此所有事件都在同一條執行緒迴圈中完成
io多路復用適合高吞吐量服務端使用，io開銷小，釋放緊缺的執行緒資源處理業務邏輯，nginx，jetty，tomcat，netty都在使用
關於Redis命令keys在效能方面的說明
redis的keys命令類似於mysql的like命令，無非就是模糊匹配相近的字元資料。keys 的速度非常快，但在乙個大的資料庫中使用它仍然可能造成效能問題，如果你需要從乙個資料集中查詢特定的 key 最好還是用 redis 的集合結構 set 來代替，我們在實際生產環境中請求併發比較多的地方還是...
效能調優 CPU方面,記憶體方面
innodb儲存引擎一般都應用於oltp的資料庫應用，這種應用的特點如下所示 使用者操作的併發量大。事務處理的時間一般比較短。查詢的語句較為簡單，一般都走索引。複雜的查詢較少。可以看出，oltp的資料庫應用本身對cpu的要求並不高，因為複雜的查詢可能需要執行比較 排序 連線等非常耗cpu的操作，這些...
影響mysql的效能主要方面
併發量 同一時間資料庫伺服器處理的請求數量 同時連線量 比 併發量 大的多得多連線數會有上千，很多處於sleep狀態，好比nignx有很多請求連線，其中幾個是請求資料庫處理的,mysql連線數預設為100 max connections定義的，生成模式可以設定大一些，若連線數滿了，會出現500的錯誤...