“Java性能权威指南笔记”的版本间的差异

来自Dennis的知识库
跳转到: 导航搜索
第16行: 第16行:
 
一些工具:
 
一些工具:
 
* 负载生成工具:http://faban.org/
 
* 负载生成工具:http://faban.org/
* t 检验: https://en.wikipedia.org/wiki/Student%27s_t-test
+
* t 检验: https://en.wikipedia.org/wiki/Student%27s_t-test 以及 [TTest](http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/stat/inference/TTest.html)

2016年5月17日 (二) 00:56的版本

全面的性能优化

  • 编写更好的算法
  • 编写更少的代码
  • 过早优化,大的架构或者算法调整不必过早,但是细节性的代码改进应当时刻注意。
  • 其他系统可能是瓶颈。
  • 常见的优化:借助性能分析来优化代码,关注性能分析中最耗时的部分;利用奥卡姆剃刀原则来诊断性能问题,最可能也最容易解释的:新代码比机器配置更可能引入性能问题,机器配置比JVM或者操作系统的 Bug 更容易引入性能问题,隐藏的Bug 可能存在,但是不应该把最可能引起性能问题的原因首先归咎于它,而只有在测试用例通过某种方式触发了隐藏的 Bug 时才关注,但是不应该一上来就跳到这种不太可能出现的场景;为应用中最常用的操作编写简单的算法。

性能测试方法

  • 原则1: 测试真实的应用,编写微基准、介基准和宏基准测试,来分别测试微小代码单元、需要复杂代码调用某方面的功能、以及整体应用。一个好的测试,应该是必须使用测试的结果(防止被优化忽略),不要包括无关的操作(例如随机数据生成,应该是提前准备好),并且必须输入合理的参数。宏基准测试要考虑到多个 JVM 系统在一台机器上的影响,他跟单 JVM 系统的结果是不同的,其实这里还应该考虑虚拟化的影响。
  • 原则2: 理解批处理流逝时间、吞吐量和响应时间。批处理流逝时间要考虑程序的热身,吞吐量就是衡量 TPS、QPS,而响应时间有两个指标——平均响应时间和百分位请求数(比如 90% 请求的响应时间)。
  • 原则3: 用统计方法应对性能的变化,统计学上的 t 检验,提供性能变化本身的置信度。
  • 原则4: 尽早频繁测试,自动化一切、测试一切(收集所能想到的所有数据)、在真实系统上运行测试。

一些工具:

个人工具
名字空间

变换
操作
导航
工具箱