阿里P8架构师谈：应用后端+移动端的性能优化指标，以及性能优化方法

性能优化专题

阿里P8架构师谈：MySQL数据库的索引原理、与慢SQL优化的5大原则

阿里P8架构师谈：Web前端、应用服务器、数据库SQL等性能优化总结

大型网站Web前端优化最佳实践，以及最全优化工具集锦

阿里P8架构师谈：多线程、架构、异步消息、Redis等性能优化策略

性能问题简介

应用性能是产品用户体验的基石，性能优化的终极目标是优化用户体验。当我们谈及性能，最直观能想到的一个词是“快”，Strangeloop在对众多的网站做性能分析之后得出了一个著名的3s定律“页面加载速度超过3s，57%的访客会离开”,可见页面加载速度对于互联网产品的重要性。

性能指标

性能优化是个系统性工程，涉及到后端、前端、移动端、系统网络及各种基础设施，每一块都需要做各自的性能优化。当我们系统的分析性能问题时，可以通过以下指标来衡量：

1.Web端：首屏时间、白屏时间、可交互时间、完全加载时间等。

首屏时间是指从用户打开网页开始到浏览器第一屏渲染完成的时间，是最直接的用户感知体验指标，也是性能领域公认的最重要的核心指标。

首屏时间 = DNS时间 + 建立连接时间 + 后端响应时间 + 网络传输时间 + 首屏页面渲染时间

2.移动端：Crash率、内存使用率、FPS（Frames Per Second, 每秒传输帧数）、端到端响应时间等。

Native相比于H5在交互体验方面有更多的优势，FPS是体现页面顺畅程度的一个重要指标，另外移动端开发同学还需要关注App进程的CPU使用率、内存使用率等系统性能指标。端到端响应时间是衡量一个API性能的关键指标，比纯后端响应时间更全面，它会受到DNS、网络带宽、网络链路、HTTP Payload等多个因素的影响。端到端响应时间是DNS解析时间、网络传输时间及后端响应时间的总和。

3.后端：响应时间（RT）、吞吐量（TPS）、并发数等。

QPS: 每秒钟处理完请求的次数；注意这里是处理完。具体是指发出请求到服务器处理完成功返回结果。可以理解在server中有个counter，每处理一个请求加1，1秒后counter=QPS。
TPS：每秒钟处理完的事务次数，一般TPS是对整个系统来讲的。一个应用系统1s能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求，对于衡量单个接口服务的处理能力，用QPS比较多。
并发量：系统能同时处理的请求数
RT：响应时间，处理一次请求所需要的平均处理时间。后端系统响应时间是指系统对请求做出响应的时间（应用延迟时间），对于面向用户的Web服务，响应时间能很好度量应用性能，会受到数据库查询、RPC调用、网络IO、逻辑计算复杂度、JVM垃圾回收等多方面因素影响。

对于高并发的应用和系统，吞吐量（TPS）是个非常重要的指标，它与request对CPU、内存资源的消耗，调用的外部接口及IO等紧密关联。

计算关系：

QPS = 并发量 / 平均响应时间
并发量 = QPS * 平均响应时间

影响性能的因素

互联网产品是创意、设计、研发、系统、网络、硬件、运维等众多资源相互交织的集合体，性能受多方面因素影响，犹如一只木桶，木桶能盛多少水，取决于最短的那块木板，也可称之为短板效应。影响产品性能的因素有：

1. 产品逻辑与用户行为

产品逻辑过于复杂、功能交互过于丰富、产品设计过于绚丽、页面元素素材过多等都会影响产品性能。

2. 基础网络

中国的基础网络是世界上最复杂的基础网络，国内的网络运营商众多且各自为政，互联互通成本很高。对于境外业务来说更是要面对国内国际网络交互的情况，再加上GFW的存在，网络延迟、丢包现象非常严重。

3. 代码及应用

开发语言瓶颈、代码质量及系统架构等都会影响系统性能，常见的代码及应用问题有：

架构不合理。业务发展超越架构支撑能力而导致系统负荷过载，进而导致出现系统奔溃、响应超时等现象。另外不合理的架构如：单点、无cache、应用混部署、没有考虑分布式、集群化等也都会影响性能。
研发功底和经验不足。开发的App、Server效率和性能较低、不稳定也是常见的事情。
没有性能意识，只实现了业务功能不注意代码性能，新功能上线后整体性能下降，或当业务上量后系统出现连锁反应，导致性能问题叠加，直接影响用户体验。
多数的性能问题发生在数据库上。由慢SQL（详情可以参考阿里P8架构师谈：MySQL慢查询优化、索引优化、以及表等优化总结）、过多查询等原因造成的数据库瓶颈，没有做读写分离、分库分表等。