一份平民化的应用性能优化检查列表（完整篇）--转
原文地址：http://calvin1978.blogcn.com/articles/checklist.html
1.總原則
一些正確但稍顯廢話的原則，但能指導后面每個章節的優化，所以還是要啰嗦一次。
?
2.環境準備
保證符合自家各種規范（沒有的話趕緊回家寫一個），尤其線下壓測服務器的配置要與生產環境一致。
2.1 操作系統
- 自家規范調優應包含TCP內核參數，網卡參數及多隊列綁定，IO&Swap內核參數，ulimit資源限制等。
2.2 JVM與應用服務器
- 使用JDK7.0 u80 或 JDK8 最新版。
- 檢查JVM啟動參數已按自家規范調優，見《關鍵業務系統的JVM參數推薦》
- 檢查應用服務器(Tomcat或微服務容器) 已按自家指南調優，如線程數等。
2.3 周邊依賴系統
- 檢查數據庫，緩存，消息系統，已按自家指南調優。
2.4 后臺輔助程序
- 檢查日志收集，系統監控等，已使用最新版本，最優配置。
- 最好其最大消耗已被控制（通過cgroup，taskset等方式）。
2.5 測試程序
- 壓測工具如JMeter，啟動參數要參考真實應用客戶端的參數優化（如JVM參數，Netty參數等）。
- 測試腳本和客戶端程序經過review，不存在影響性能的步驟，不存在System.out.println（）等明顯的瓶頸。
2.5 流量模型
- 扇入模型：平時與高峰期的流量估算，各接口的流量比例，響應時間要求
- 扇出模型：各接口對遠程服務、數據庫、緩存、消息系統的調用比例，響應時間估算。
?
大家在心里都有這么一個大概的模型，但很少認真寫出來。
行文到此，大家大概可以感受到這份checklist的風格，都是大家明白的道理，但可能一時也會忘掉的，這里啰啰嗦嗦的給寫下來。
3.數據庫
特別鳴謝，我司DBA。
3.1 拓撲
根據擴展性原則考慮：
- 垂直拆分：按業務將不同的表拆分到不同的庫。
- 水平拆分：水平分庫分表。
- 讀寫分離：在業務允許的情況下，在從庫讀取非實時數據。
3.2 Schema
自家規范應包含：
- 統一的存儲引擎，主鍵策略。
- 禁用存儲過程，函數，觸發器，外鍵約束。
- 列類型永遠越短越好，建議：布爾/枚舉：tinyint，日期與時間戳：timestamp或int，char/text/blob: 盡量用符合實際長度的varchar（n），小數及貨幣：移位轉為int 或 decimal，IP地址：int。
- 索引策略：索引字段的順序需要考慮字段值去重之后的個數，較多的放前面，合理創建聯合索引，避免冗余索引，合理利用覆蓋索引等。
?
3.3 SQL
1. 自家規范應包含：
- 如禁止多于3表join，禁用子查詢
- 禁止where子句中對字段施加函數，如to_date（add_time）>xxxxx
- 避免MySQL進行隱式類型轉化，如ISENDED&eq;1 與 ISENDED&eq;`1`
- 不建議使用%前綴模糊查詢，模糊查詢較多時建議使用ElasticSearch
?
根據盡量少數據原則與盡量少交互的原則來設計SQL:
- 禁止select?＊
- 合理的SQL語句，減少交互次數
根據擴展性原則，將負載放在更容易伸縮的應用服務實例上：
- 盡量不要做數學運算，函數運算, 或者輸出格式轉換等非必要操作
- 避免count（＊），計數統計實時要求較強使用memcache或者redis，非實時統計使用單獨統計表，定時更新。
- 甚至排序都是不鼓勵的，盡量在應用側進行。另外避免多余的排序，使用GROUP BY 時，默認會進行排序，當你不需要排序時，可以使用order by null。
2.?聯系DBA進行MySQL統計的慢查詢的Review，解析SQL查詢計劃時盡量避免extra列出現：Using File Sort，Using Temporary
3.4 DAO框架
- 根據盡量少交互與盡量少數據的原則，需使用對SQL完全可控的DAO框架，建議為MyBatis 或 Spring JDBC Template。
- 必須使用prepareStatement，提升性能與防注入。
- 根據一切皆有超時的原則，配置SQL執行的超時。可在連接池里設置default值，可在MyBatis的Mapper定義里可設置每個請求的超時，可惜規范是秒級的。
- JDBC driver 規范本身不支持異步模式，如果一定要異步，可以像Quasar那樣把請求封裝成Callable交給另外的線程池執行，但要注意其額外開銷。
?
3.5 事務
- 不使用事務，連接池設置autocommit，使用其他方式來保持數據一致性。
- 通過Transaction?Annotation控制事務，事務跨度盡量短，把非事務范圍內的業務邏輯剔除到被標注的函數之外。
- 只讀事務可以不加事務標注。
?
連接池
選型：
- 在分庫分表時，根據點對點通信優先的原則，盡量使用客戶端分片的實現。功能不滿足時才用MyCat中央代理。
- 推薦使用性能最高HikariCP，或者Druid，不推薦c3p0與DBCP。
?
連接池的配置：
- 配置初始值，再聯系DBA獲得線上數據庫支持的連接數，計算最大連接數。
- 連接有效性檢查，只在連接空閑檢測時執行，不在拿出和歸還連接時執行，最好是直接使用數據的Ping方案，不要配置檢查SQL。
- 根據總是設置超時的原則，配置獲取連接超時的時間。
- 配置合理的空閑連接回收間隔和空閑時間。
番外篇：在分庫分表時，可考慮基于HikariCP二次開發，減少總的空閑連接檢查線程數（比如128個分區，可能有256條線程），重用同一個實例上的庫的連接等。
4.緩存
?
4.1 多級緩存
?
- 根據緩存原則， 緩存 > 數據庫/遠程調用
- 根據就近原則， 堆內緩存 > 堆外緩存 > 集中式緩存
- 堆內緩存受大小限制，并影響GC
- 堆內緩存與堆外緩存，分布在每一臺應用服務器上，刷新方式比集中式緩存復雜
- 堆外緩存與集中式緩存，需要序列化/反序列化對象
- 集中式緩存，有網絡傳輸的成本，特別是數據超過一個網絡包的大小。
- 集中式緩存，一次獲取多個鍵時，在有分區的情況下，需要收發多個網絡包。
使用上述條件選擇合適的緩存方案，或同時使用多級緩存，逐層回源。
?
4.2 綜述
- 需要對回源進行并發控制，當key失效時，只有單一線程對該key回源。
- 基于二進制優于文本數據的原則，JSON的序列化方案較通用與更高的可讀性。而對于較大，結構較復雜的對象，基于Kyro，PB，Thrift的二進制序列化方案的性能更高，見后面的序列化方案部分。
?
4.3 堆內緩存
選型：
- 推薦Guava Cache。
- Ehcache較重，性能也較差。更不要使用存在嚴重bug的Jodd Cache。
GuavaCache：
- 正確設置并行度等參數。
- 重載load（）參數，實現單一線程回源。
- Guava Cache能后臺定時刷新，在刷新的過程中，依然使用舊數據響應請求，不會造成卡頓，但需要重載實現reload（）函數。
- Guava Cache同時還支持并發安全版的WeakHashMap。
?
4.4 堆外緩存
選型：
- 推薦Cassandra的OHC 或者 OpenHFT的Chronical map2。
- OHC夠簡單，其實R大不喜歡Chronical，玩的太深，換個JDK都可能跑不起來。
- Chronical map3的license則較不友好，復雜度高且要求JDK8。
- 其他的Ehcache的Terracota Offheap 一向不喜歡。
4.5 Memcached
?客戶端：
- 基于點對點通信優于網關的原則，使用客戶端一致性哈希分區。
- 推薦Spymemcached。 XMemcached 太久沒更新，Folsom知名度不高。
- 注意Spymemcached為單線程單連接架構（一個MemcachedClient只有一條IO線程，與每臺Memcached只有一條連接），必要時可多建幾個MemcachedClient隨機選擇，但不要用Commons Pool去封裝它，把Spy原本的設計一筆抹殺。
- 根據在合適場景使用并發的原則，Spymemcached支持異步API。
- 根據一切皆設超時的原則，可在連接工廠中設置最大超時數，默認值兩秒半太長。
?
數據結構：
- Key必須設置失效時間。
- Key必須有長度限制。
- Value長度需要控制，以不超過1個網絡包（MTU，千五字節）為佳。
- Value大小差別較大的緩存類型，建議拆分到不同MC集群，否則會造成低使用率并且產生踢出。
?
4.6 Redis as Cache
?
Redis拓撲：
基于點對點通信優于網關的原則，使用如下兩種拓撲
- 無HA的普通分片：由Jedis客戶端完成分片路由。
- Redis Cluster：同樣由Jedis客戶端封裝分區，跳轉，重試等邏輯，需要使用最新版的Jedis版本。
?
服務端：
- Cache節點與持久化數據節點不要混用。
- Cache節點是否需要持久化要仔細衡量。
- 由于Redis是單線程，使用taskset進行cpu綁定后可以有效地利用cpu，并在單機上運行多個redis實例。
- 對熱鍵進行監控，發現不合理的熱健要進行分拆等處理。
客戶端：
- Jedis基于Apache Commons Pool進行了多連接的封裝，正確配置總連接數不超過Redis Server的允許連接數。
- 性能考慮，空閑連接檢查不要過于頻繁（建議30秒以上），另不要打開testOnBorrow等測試參數。
- 根據一切皆有超時的原則，設定統一的調用超時，獲取連接的最長等待時間參數，重試次數
- 根據在合適的地方異步的原則，Jedis本身沒有異步API，只在PipleLine模式下支持。
數據結構：
- 必須對Key設置失效時間。
- Key必須有長度限制。
- Value長度需要控制，不要超過一個網絡包。另外集合的元素不要超過五千個。
- 除了使用序列化的String，同樣可以考慮用Hash來存儲對象，注意內部結構為ZipList與HashTable時，hmget?與hgetall的不同復雜度。
命令：
- 慎用的命令：LANGE（0, -1）, HGETALL, SMEMBER
- 高復雜度的命令: ZINTERSTORE, SINTERSTORE, ZUNIONSTORE, ZREM
- 盡量使用多參數的命令：MGET/MSET，HMGET/HMSET, LPUSH/RPUSH, LRANGE
- 盡量使用pipeline
- 根據減少交互的原則，必要時可使用Redis的Lua腳本
?
5.服務調用
5.1 接口設計
1. 盡量少交互的原則：
支持批量接口，最大的批量，綜合考慮調用者的需求與 后端存儲的能力。
支持粗粒度接口，在支持原子細粒度接口的同時，支持粗粒度接口/聚合層接口，將多個數據源的獲取，多個動作，合并成一個粗粒度接口。
?
2. 盡量少數據的原則：
在提供返回所有數據的大接口的同時，提供只提供滿足部分調用者需要的輕量接口。
最好再提供能定制返回字段的接口。
?
3. 二進制數據優于文本數據
同樣是一個簡單通用性，與性能的選擇，特別是大數據量時。
?
5.2 RESTful
僅以Apache HttpClient為例，大部分Restful框架都是對Apache HttpClient的封裝。
另外OkHttp也值得看看。
?
- 不要重復創建ApacheClient實例，使用連接池，正確配置連接池的連接數。
- 連接池總是有鎖，針對不同的服務，使用不同的Apache HttpClient實例，將鎖分散開來。在高并發時比使用全局單例的ApacheClient，有很大的性能提升。
- 根據一切調用皆有超時的原則，每次調用均設置超時時間。RequestConfig里共有Connect Timeout, Socket Timout 和 從Pool中獲取連接的Timeout三種超時。
- 需要異步或并行的場景，使用Apache AsyncHttpClient項目。但要注意AsyncHttpClient項目，檢查調用超時的周期默認為1秒。
?
5.3 自家RPC框架
?
每家的RPC框架特性不同，但考慮點都類似。
?
?
6.消息異步
?
6.1 選型
- 根據就近原則，可以先嘗試用JVM內的隊列來解決，然后再考慮中央消息系統。
- 可靠性要求極高的選擇RabbitMQ，可支持單條消息確認。
- 海量消息場景，允許極端情況下少量丟失則使用Kafka。
?
6.2 Kafka
- 在同步和異步之間做好權衡，異步批量發送可以極大的提高發送的速度。
- 關注消費者如下參數：commitInterval(自動提交offset間隔)，prefetchSize(指單次從服務器批量拉取消息的大小)，過大和過小都會影響性能，建議保持默認。
?
6.3 RabbitMQ
- 根據擴展性原則，RabbitMQ本身沒有分片功能，但可以在客戶端自行分片。
- 如非必要情況，應該保持默認的同步發送模式。
- 關注消費者如下參數：autocommit(自動提交確認，默認false) ，在消息拉取到本地即認為消費成功，而不是真正消費成功后提交。prefetchCount(預取消息條數，默認64條)
- 生產者在必要時也可以臨時降級不進行confirm。
?
7. 日志
?
7.1 綜述
- Log4j2或logback，不要再使用Log4j。
- 除了應用啟停日志，不允許使用超慢的System.out.println() 或 e.printStack();
- 嚴格控制日志量避免過高IO，對海量日志，應該有開關可以動態關停。
- 如果可能出現海量異常信息，可仿效JDK的優化，用RateLimiter進行限流，丟棄過多的異常日志。
7.2 內容
- 嚴格控制日志格式，避免出現消耗較大的輸出如類名，方法名，行號等。
- 業務日志不要濫用toJSONString（）來打印對象，盡量使用對象自身的toString()函數，因為JSON轉換的消耗并不低。
- 在生產環境必定輸出的日志，不要使用logger.info（"hello?{}", name）的模式，而是使用正確估算大小的StringBuilder直接拼裝輸出信息。
?
7.3 異步日志
- 同步日志的堵塞非常嚴重，特別是發生IO的時候，因此盡量使用異步日志。
- Logback的異步方案存在一定問題，需要正確配置Queue長度，閥值達到多少時丟棄Warn以下的日志，最新版還可以設置如果隊列已滿，是等待還是直接丟棄日志。
- 如果覺得Logback的異步日志每次插入都要詢問隊列容量太過消耗，可重寫一個直接入列，不成功則直接丟棄的版本。
?
8. 工具類
?
8.1 JSON
- 使用Jackson 或 FastJSON。GSON的性能較前兩者為差，尤其是大對象時。
- 超大對象可以使用Jackson或FastJSON的流式 API進行處理。
- 將不需要序列化的屬性，通過Annotation排除掉。
FastJson：
- 盡量使用最新的版本。
- SerializerFeature.DisableCircularReferenceDetect 關閉循環引用檢查。
Jackson：
- 設置參數，不序列化為空的屬性，等于默認值的屬性。
- 除了jackson-databinding，可試用簡化版沒那么多花樣的jackon-jr。
?
8.2 二進制序列化
?
需要定義IDL的PB與Thrift，不需要定義的Storm等用的Kyro 都可選擇，其他一些比較舊就算了。
8.3 Bean復制
在VO，BO之間復制時，使用Orika（生成代碼） 或 Dozer（緩存反射），不要使用需要每次進行反射的Apache BeanUitls，Spring BeanUtils。
?
8.4 日期
JDK的日期類與字符串之間的轉換很慢且非線程安全。
繼續用Java日期不想大動作的，就用CommonsLang的FastDateFormat。
能大動作就用joda time，或者JDK8的新日期API。
?
9.Java代碼優化 與 業務邏輯優化
?
參考《Java調優指南1.8版》，對內存使用，并發與鎖等方面進行優化。
?
規則前置，將消耗較大的操作放后面，如果前面的條件不滿足時可。
另外前面提到的一堆原則，比如盡量緩存，盡量少交互，盡量少數據，并行，異步等，都可在此使用。
轉載于:https://www.cnblogs.com/davidwang456/p/6932852.html
總結
以上是生活随笔為你收集整理的一份平民化的应用性能优化检查列表（完整篇）--转的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 微服务实战（七）：从单体式架构迁移到微服
- 下一篇： 美团配送资金安全治理之对账体系建设