java 性能优化实践——性能测试模式

	/**
     * java 性能优化实践
     *  性能测试模式和反模式
     *      性能测试模式
     *          --有总比没有好
     *          好的性能测试是可以量化的，提出一个问题能够得到一个数字化的答案，用于作为实验输出来处理并进行统计分析
     *
     *          @延迟测试
     *              端到端的交易时间是多少？
     *                  客户端点击支付到支付完成花费时间？
     *              延迟进行调优其目标通常是直接改善用户体验。
     *                  或者满足服务等级协议SLA——服务提供者和用户签订商务合同协议，以满足用户对于服务的要求标准
     *              对于衡量应用程序对请求的响应程度，简单的平均数并不是很有用。
     *                  不具有稳定性的系统参考。
     *
     *          @吞吐量测试
     *              目前的系统容量能够处理多少个并发交易?
     *              当进行延迟测试时，即在生成延迟结果的分布时，需要说明和控制正在进行的交易并发数
     *              所观测到的系统延迟应该在已知和受控的吞吐量水平下给出。————吞吐量量化能够保证延迟测试的稳定性准确性
     *
     *              当我们在监控延迟的同时进行吞吐量测试。
     *              通过留意延迟分布何时会突然发生变化——实际上是系统的一个临界点（拐点）来判断吞吐量
     *              吞吐量测试是确定系统在降级之前观测到的最大吞吐量
     *
     *          @负载测试
     *              系统能够处理某个特定的负载？
     *              定义为二进制测试，即系统能不能处理这个预设的负载
     *                  流量激增，广告活动，社交媒体和病毒式营销——不可预测的增长趋势？
     *
     *          @压力测试
     *              系统的临界点是什么？
     *              压力测试的目的就是确定系统的拐点以及它们出现时的负载水平。
     *              确定系统还有多少余量空间的方法
     *                  该测试系统将系统处于稳定的交易状态下进行，也就是在某个指定的吞吐量水平之下
     *                  然后不断的增加交易数，直到我们开始观测到系统数据开始下降
     *                  通过观测下降的值就可以确定系统在吞吐量测试中可以达到的最大吞吐量
     *
     *          @耐久性测试
     *              系统长期运行时会发现哪些性能异常现象？
     *              有些问题只有在更长的时间内才会出现——路遥知马力
     *                  缓慢的内存泄漏，高速缓存污染和内存碎片化
     *
     *          @容量规划测试
     *              当增加额外的资源时，系统的规模能够按照预期的扩展
     *              确定系统在升级后能承受的负载
     *
     *          @退化测试
     *              当系统出现故障时会出现什么情况？
     *              当系统部分组件失去能力时，系统会有何种表现？
     *              主要观测对象包括交易延迟分布和吞吐量
     *
     *              混淆猴
     *                  在一个真正的弹性架构中，单个组件的故障不应该导致级联故障，也不应该对整个系统造成影响
     *                  系统卫生，服务设计，运维优势
     *
     *      @实践入门
     *          #确定你所关心的是什么？如何去衡量它！
     *          #优化重要的东西而不是容易的东西
     *          #抓住要点
     *
     *          @自上而下性能测试
     *              从整个应用程序性能入手，自上而下性能测试
     *              自下而上的性能测试可能做到这么大吗？
     *
     *           @创建一个测试环境
     *              对生产环境的各种标准的精确复制
     *                  复制的原因是因为我们需要这样的环境中提供到预测生产环境的能力
     *              也可以是通过测试环境最终确定生产环境的最终标准和更新
     *
     *              对于基础设施的精确性追求一定是有必要的，首先考虑中断服务带来的后果
     *              动态化的基础设施管理方法正在普及
     *                  宠物模式和畜生模式
     *          @确定其性能要求
     *              系统是一个整体，代码是其中一部分
     *              非功能性需求NFR（nonfunctional requirement）
     *                  客户和管理层都很重要的观测量是我们重要的优化关键指标
     *                      比如
     *                         将95%的交易时间减少100ms
     *                         改进系统，使现有硬件上的吞吐量提高5倍
     *                         将平均响应时间减少30%
     *              精确化——测量内容和要达到的目标
     *
     *          @java特有的问题
     *              java一个重要问题和JIT有关
     *                  现代JVM会分析哪些方法正在运行，以选定可以进行JIT编译的候选方法。并为其生产优化的机器代码
     *                  这意味着如果一个方法没有被编译，会处于两种情况
     *                      该方法的运行频率不够高，无法被编译
     *                      该方法太大或太复杂，无法进行编译分析
     *
     *         @性能测试当做软件开发生命周期的一部分
     *              有经验的团队往往会持续进行性能测试，特别是会把性能回归测试当做软件开发生命周期中不可或缺的而一部分
     *                  开发团队和基础架构团队之间的协作，必须协作
     *                  以控制在任何特定时间内性能测试环境中要出现的代码版本——专门的测试环境
     */