说明
讲师：李智慧
架构师用了很多优化手段，如何给老板证明，性能提升了呢/p>
性能测试
性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。不同视角下的 站性能有不同的标准，也有不同的优化手段。
- 主观视角：用户感受到的性能。
（支付转账场景，用户点击转账后，有个倒计时的页面，即时反馈给用户，让用户感受到快。） - 客观视角：性能指标衡量的性能。
性能测试指标
不同视角下有不同的性能标准，不同的标准有不同的性能测试指标， 站性能测试的主要指标有响应时间、并发数、吞吐量、性能计数器等。
响应时间
响应时间：指应用系统从发出请求开始到收到最后响应数据所需要的时间。响应时间是系统最重要的性能指标，直观的反映了系统的“快慢”。
并发数
并发数：系统能够同时处理请求的数目，这个数字也反映了系统的负载特性。对于 站而言，并发数即系统并发用户数，指同时提交请求的用户数目，于此相对应，还有在线用户数（当前登录系统的用户数）和系统用户数（可能访问系统的总用户数）。
吞吐量
吞吐量：指单位时间内系统处理的请求的数量，体现系统的处理能力。对于 站，可以用 “请求数/秒” 或是 “页面数/秒” 来衡量，也可以用 “访问人数/天” 或是 “处理的业务数/小时” 等来衡量。
- TPS(每秒事务数)也是吞吐量的一个指标，此外还有HPS（每秒HTTP请求数）。
- QPS(每秒查询数)。
吞吐量 = (1000 / 响应时间ms) * 并发数
性能计数器
性能计数器：是描述服务器或操作系统性能的一些数据指标。包括 System Load、对象与线程数、内存使用、CPU 使用、磁盘与 络 I/O 等指标。这些指标也是系统监控的重要参数，对这些指标也是系统监控的重要参数，对这些指标设置 警阀值，当监控系统发现性能计数器超过阀值的时候，就向运维和开发人员 警，及时发现处理系统异常。
命令查看，Load Avg：正在处理的线程数 + 正在等待的线程数，三个时间段的平均时间。理想情况下是CPU的核数。
如果大于CPU的核数，表示CPU过载；如果小于CPU的核数，表示CPU空闲，资源利用不足。
让系统在b点位置左右运行；如果在c点位置左右，那么就很容易系统奔溃了。
到底是在b点位置的左还是右呢要依赖于投资多少钱的机器。如果要省钱，那么在b点靠右的位置，安全性会低一点，到达c点比较危险。如果不差钱，那么可以多加机器(比如银行)，那么就在b点靠左的位置。
响应时间
性能测试压测可用性
软件性能优化的两个基本原则
- 你不能优化一个没有测试的软件。
- 你不能优化一个你不了解的软件。
新来架构师，一看系统就觉的技术架构很落伍，要用业界比较牛的架构重构。一般这种架构师撑不过试用期。别这样，千万别这样。毕竟技术团队花了很长的时间在这套系统里面，要先了解系统。了解问题，比掌握技术更关键。不要盲目的那所谓的牛逼技术到处用。不要拿着锤子??去砸钉子，要先找到钉子。
性能测试的主要指标
- 响应时间：完成一次任务花费的时间。
- 并发数：同时处理的任务数。
- 吞吐量：单位时间完成的任务数。
- 性能计数器：System Load, 线程数，进程数，CPU，内存，磁盘， 络使用率。
Spark 应用性能测试
使用更优的CPU，磁盘，内存， 卡，对软件的性能优化可能是数量级的，有时候远远超过代码和架构的性能优化。
优化方案：升级 卡，10G 卡代替1G 卡。
操作系统性能优化案例
资源利用分析，发现大量 CPU 操作为 sys 类型，消耗大量计算资源。
调查发现，起因是部分 Linux 版本缺省情况下打开 transparent huge page 导致。
优化方案：关闭 transparent huge page。
- 架构更轻量；
- 配置更简单；
- 应用更无状态化，开发和维护的福音；
- 更加安全。
阿里巴巴应用服务器升级项目：
Apache2.2 + Mod – Proxy + Jetty 7.1.5 与阿里巴巴现有架构性能对比
异步
- 即时响应，更好的用户体验。
- 控制消费速度，合适的负载压力。
- 异步主要优化写操作。
集群
古老谚语：如果一匹马拉不动车，无需换一匹更强的马，而是用两匹马拉车。
互联 技术的发展路径是：更多的用户访问需要消耗更多的计算机资源，单一服务器计算资源的增加是有极限的，所以需要增加更多的服务器。关键是如何利用起来这些服务器。
集群的技术目标只有一个：如何使很多台服务器对使用者而言看起来像一台服务器。
- 优化方案： Executor 加载应用程序包启用本地文件缓存模式。[SPARK-2713]
- 优化效果：Stage1 运行时间从14s下降到不到1s。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！