wiki

您的足迹:

分享:技术:性能调优:性能调优

差别

这里会显示出您选择的修订版和当前版本之间的差别。

到此差别页面的链接

--- 分享:技术:性能调优:性能调优 [2016/01/25 11:24]
gxx 创建
+++ 分享:技术:性能调优:性能调优 [2016/01/29 10:09] (当前版本)
gxx
@@ 行 1: / 行 1: @@
 ====== 性能调优 ======
+===== 调优基本思路(闭环) =====
+  * 确定性能瓶颈/热点
+  * 确定优化方案
+  * 实施、反馈优化情况
+===== 确定性能瓶颈/热点的常见方法 =====
+  * 性能压测：通过工具/人肉等方式量化运行时性能情况。
+  * 业务/代码梳理：通过代码走读，发现资源消耗热点（牛B的人可以这么干）；通过统计代码对资源的操作，量化代码对资源的消耗（比如一个业务操作会进行多少次数据库调用，会进行多少次服务运算等方式）。
+===== 压测时常观察的内容及工具 =====
+这里举例java应用
+  * 压测工具：jmeter
+  * 内存的使用情况：mat，gc日志，vmstat
+  * IO情况：iostat
+  * 网络情况：netstat
+  * 热点代码：jprofile，btrace，jstack，jstat
+  * CPU情况：top
+===== 优化的常见手段 =====
+  * 静态化：动态数据和静态数据分离。
+  * 异步化：使用异步化减少主流程中的非关键业务逻辑。
+  * 并行化：使用多线程并发处理，缩短响应时间。
+  * 内存优化：减少对象大小，减少对象创造，数据模型优化。
+  * 去重复运算：业务逻辑优化，或者使用缓存。
+  * 减少数据库操作：数据冗余，数据缓存等。
+  * 缩短数据库事务：短事务，异步化，最终一致性等方式可以考虑。
+  * 精简代码逻辑：去除冗余代码，诸如过度设计检查等代码。
+  * 精简日志操作：日志大小要关注，注意IO上的瓶颈；日志太多，说明生成的string也会多，也增加了gc负担。
+===== 结构型优化常见步骤 =====
+此部分介绍的内容，在很多网站架构变迁的文章中介绍过，这里通过图的方式展现出来。
+每个阶段都有适用的软件架构，基于成本、建设复杂度、维护成本的考虑，不必强求一开始建设很完整的技术体系。
+个人认为，性能是驱动应用体系研究的重要驱动力，可以通过下面应用结构演进看出来。
+  * 单应用时代常见瓶颈先发生在DB。
+{{:分享:技术:性能调优:1.png?500|}}
+  * 单应用时代常见第一个解法是使用缓存（偏向应用级别缓存）。
+{{:分享:技术:性能调优:2.png?500|}}
+  * 单应用时代常见第一个解法是独立缓存服务（集中式缓存，如memcache）。
+{{:分享:技术:性能调优:3.png?500|}}
+  * 单应用集中式部署带来应用集群处理能力提升。
+{{:分享:技术:性能调优:4.png?500|}}
+  * 单应用集中式部署部署后的DB瓶颈。
+{{:分享:技术:性能调优:5.png?500|}}
+  * 单应用集中式部署部署后的DB瓶颈解法（数据库拆分、读写分离）。
+{{:分享:技术:性能调优:6.png?500|}}
+  * 服务化拆分应对更大范围请求量。
+{{:分享:技术:性能调优:7.png?500|}}
+  * 服务化集群部署模式。
+{{:分享:技术:性能调优:8.png?500|}}
+===== 性能/应用优化的几个趋势 =====
+{{:分享:技术:性能调优:9.png?500|}}
+===== 参考帖子 =====
+http://dwz.cn/2DL5U3

分享/技术/性能调优/性能调优.1453692242.txt.gz · 最后更改: 2016/01/25 11:24 由 gxx