网站性能优化

好的性能是设计出来的，而不是优化出来的。
最好是在产品设计阶段就做好性能方案设计，如果产品没有做好就需要开发人员意识到这些问题，如果开发人员也没有意识到那么就需要测试阶段做好细致和周全的思考，如果测试阶段也没做好就只能上线后等用户打脸了。其中的代码是向后递增的。
性能优化是遵循三条原则来进行的：问题定位、问题解决、问题泛华。

性能指标与关注点

从产品经理拿到产品设计文档的时候，性能指标应当是有一定长度的明确了。性能指标一般由两大类：业务角度、资源角度。

业务角度

关注延迟和吞吐量。延迟一开始可以说几乎不变，到了某一个特定的值后延迟突然迅速增大。吞吐量总是一个先线性增大，后缓慢增长，到达峰值后逐渐缩小的过程。

如果我们不做流量控制，在系统压力达到一定程度的时候，系统并非只能做它力所能及的工作，而往往是什么都做不成了。

其他业务角度的性能指标：

• TPS、QPS：每秒处理事务数、每秒处理查询数量
• 并发用户数：在同一时间有多少用户在使用系统
• TP99：指全球中 99% 的请求能达到的性能

资源角度

资源一般是指机器资源。平均使用率和峰值是两个比较关心的数据。

一般我们会以一个把系统上限的一个比例当做安全阈值，一旦超过就要进行告警。

寻找性能瓶颈的思路：

• 首先要对系统有一个大致的预期。
• 其次过一遍待优化业务的环境、配置、代码，对整个请求的处理流程做到心中有数。
• 再次，开始压测。缓慢、逐步增大请求速率，直到预期的业务角度的性能指标无法再提升，待系统稳定。
• 最后才是根据业务角度的指标来进行特定的分析。

分析延迟：从大的流程到小的环节，从操作系统到应用本身，逐步定位端到端的时间消耗在了哪里。
分析吞吐量：这类问题 CPU 是核心，因为 CPU 是实实在在在工作的。

• 吞吐量逐步上升，CPU 变化很小 —— 说明系统还能扛，增大请求速率。
• 吞吐量逐步上升，CPU 平稳上升 —— 正常现象，继续拉升直到 CPU 瓶颈。
• 吞吐量变化很小甚至回落，CPU 大幅上升 —— CPU 在干一些预期外的活，典型的就是内存泄露。
• 吞吐量上不去，CPU 也上不去 —— 有硬件成为了 CPU 拉升的瓶颈，检查硬件、网络等外部因素。