架构师视角也就是从系统的全链路视角，来分析系统性能指标
一、一次请求全链路图
步骤一：DNS解析，，用户在浏览器输入URL按回车，请求会进行DNS查找，浏览器通过DNS解析查到域名映射的IP地址，查找成功后，浏览器会和该IP地址建立连接。对应的性能指标为：DNS解析时间。对于这个指标，我们可以通过DNS缓存或DNS预解析，适当增大域名的TTL值来增大DNS服务器缓存域名的时间，进而提升了缓存的命中率。也可以用dns-prefetch标签实现域名的预解析，让浏览器在后台把要用的DNS请求提前解析，当用户访问的页面中包含了预解析的域名时，再次解析DNS就不会有延迟了。
步骤二：建立TCP连接，由于HTTP是应用层协议，TCP是传输层协议，所以HTTP是基于TCP协议基础上进行数据传输的，所以你要建立TCP请求连接，这里也可以用TCP的连接时间来衡量浏览器与Web服务器建立的请求连接时间。
步骤三：服务器响应
这部分是一个最重要的新能指标，即服务器端的延迟和吞吐能力，针对影响服务端性能的指标，还可以细分为基础设施性能指标、数据库性能指标，以及系统应用性能指标。
基础设施性能指标主要针对CPU利用率、磁盘I/O，网络带宽、内存利用率。例如，CPU占用率超过80%，就很有可能是系统出了问题。如果内存利用率达到100%，可能是应为内存中存放了缓存，因此还要衡量SWAP交换空间的利用率，另外，还要考虑容器的 JVM 的Full GC 情况、磁盘 I/O 是否可以优化、网络带宽是否存在瓶颈等问题都会影响系统的最终性能。
数据库的性能指标主要有 SQL 查询时间、并发数、连接数、缓存命中率等。
系统应用性能指标和系统业务有关，因为业务场景影响架构设计，比如To C 的系统一般会设计成同步 RPC 调用，因为要实时反馈 C 端用户的请求，而 To B 的系统则可以设计成事件驱动模式，通过异步通知的方式，推送或拉取数据，两种架构对比，显然异步事件驱动的吞吐量会更高。
步骤四：白屏时间
当浏览器与 Web 服务器建立连接后，就可以进行数据通信了。Web 服务器接收请求后，开始处理请求，浏览器这时会等待Web 服务器的处理响应。
由于浏览器自上而下显示 HTML，同时渲染顺序也是自上而下的，所以当用户在浏览器地址栏输入 URL 按回车，到他看到网页的第一个视觉标志为止，这段白屏时间可以作为一个性能的衡量指标（白屏时间越长，用户体验越差）。
优化手段为减少首次文件的加载体积，比如用 gzip 算法压缩资源文件，调整用户界面的浏览行为（现在主流的Feed流也是一种减少白屏时间的方案）。
步骤五：首屏时间
用户端浏览界面的渲染，首屏时间也是一个重要的衡量指标，首屏时间是指：用户在浏览器地址输入 URL 按回车，然后看到当前窗口的区域显示完整页面的时间。一般情况下，一个页面总的白屏时间在 2 秒以内，用户会认为系统响应快，2 ~ 5 秒，用户会觉得响应慢，超过 5 秒很可能造成用户流失。
二、如何分析系统的性能瓶颈？
（一）设计阶段，定义系统性能目标
要在项目初期定义好系统大致的性能目标，比如希望单台服务器能够负载多少 TPS 的请求，因为不同的性能会影响到系统的架构设计，也会带来不同的成本，一旦过了设计阶段，再因为性能问题调整系统架构，成本极高。比如，当前单机性能是 80 TPS，要想优化到100 TPS，可以做一些小的性能优化，但要提升到 1000 TPS，就要进行架构改造了，代价非常大。
（二）开发阶段，走查代码和业务流程
也就是评审代码，代码包括应用程序源代码、环境参数配置、程序整个调用流程和处理逻辑。例如，用户在 App 中触发了“立即下单”按钮，服务端的应用程序从线程池里取得了线程来处理请求，然后查询了几次缓存和数据库，都读取和写入了什么数据，再把最终的响应返回给 App，响应的数据报文格式是什么，有哪些状态码和异常值……
（三）测试阶段，压测发现系统性能峰值
一般来说，要在系统上线前，对系统进行全方位的压力测试，绘制出系统吞吐量和延迟曲线，然后找到最佳性能点，并在超过最佳性能点时做限流，如果达不到最佳性能点（比如多数系统的吞吐量，随着压力增大，吞吐量上不去）就需要考虑出现延迟和吞吐量的这几种情况。
1.定位延迟问题
要本着端到端的策略，大到整体流程，小到系统模块调用，逐一排查时间消耗在哪里。
可以使用 kill -3 PID， jstack 等命令打印系统当前的线程执行的堆栈；还可以用一些性能分析工具，如 JProfiler 来监控系统的内存使用情况、垃圾回收、线程运行状况，比如发现了运行的 100 个线程里面，有 80 个卡在某一个锁的释放上面，这时极有可能这把锁造成的延迟问题。
- 对于吞吐量问题的定位
对于吞吐量指标要和 CPU使用率一起来看，在请求速率逐步增大时，经常会出现四种情况：
架构师的视角分析系统性能指标
