平均响应时间：最常用，但是缺陷很明显，对于慢请求不敏感。比如 1 万次请求，其中 9900 次是 1ms，100 次是 100ms，则平均响应时间为 1.99ms，虽然平均耗时仅增加了 0.99ms，但是 1%请求的响应时间已经增加了 100 倍。
TP90、TP99 等分位值：将响应时间按照从小到大排序，TP90 表示排在第 90 分位的响应时间， 分位值越大，对慢请求越敏感。
RPS（吞吐量）：单位时间内处理的请求量，通常由QPS和并发数决定。
通常，设定性能目标时会兼顾吞吐量和响应时间，比如这样表述：在每秒 1 万次请求下，AVG 控制在 50ms 以下，TP99 控制在 100ms 以下。对于高并发系统，AVG 和 TP 分位值必须同时要考虑。
另外，从用户体验角度来看，200 毫秒被认为是第一个分界点，用户感觉不到延迟，1 秒是第二个分界点，用户能感受到延迟，但是可以接受。
因此，对于一个健康的高并发系统，TP99 应该控制在 200 毫秒以内，TP999 或者 TP9999 应该控制在 1 秒以内。
PV：综合浏览量，即页面浏览量或者点击量，一个访客在24小时内访问的页面数量。
UV：独立访客 ，即一定时间范围内相同访客多次访问网站，只计算为一个独立的访客。
带宽： 计算带宽大小需要关注两个指标，峰值流量和页面的平均大小。
日网站带宽可以使用下面的公式来粗略计算：
日网站带宽=pv/统计时间（换算到秒）*平均页面大小（单位kB）*8峰值一般是平均值的倍数；
QPS不等于并发连接数，QPS是每秒HTTP请求数量，并发连接数是系统同时处理的请求数量:
峰值每秒请求数（QPS） = (总PV数 * 80%) /（6小时秒数 * 20%） 可用性指标高可用性是指系统具有较高的无故障运行能力，可用性 = 平均故障时间 / 系统总运行时间，一般使用几个 9 来描述系统的可用性。
对于大多数系统。2个9是基本可用（如果达不到开发和运维可能就要被祭天了），3个9是较高可用，4个9是具有自动恢复能力的高可用。要想达到3个9和4个9很困难，可用性影响因素非常多，很难控制，需要过硬的技术、大量的设备资金投入，工程师要具备责任心，甚至还要点运气。
可扩展性指标面对突发流量，不可能临时改造架构，最快的方式就是增加机器来线性提高系统的处理能力。
对于业务集群或者基础组件来说，扩展性 = 性能提升比例 / 机器增加比例，理想的扩展能力是：资源增加几倍，性能提升几倍。通常来说，扩展能力要维持在 70%以上。
但是从高并发系统的整体架构角度来看，扩展的目标不仅仅是把服务设计成无状态就行了，因为当流量增加 10 倍，业务服务可以快速扩容 10 倍，但是数据库可能就成为了新的瓶颈。
像 MySQL 这种有状态的存储服务通常是扩展的技术难点，如果架构上没提前做好规划（垂直和水平拆分），就会涉及到大量数据的迁移。
我们需要站在整体架构的角度，而不仅仅是业务服务器的角度来考虑系统的扩展性 。所以说，数据库、缓存、依赖的第三方、负载均衡、交换机带宽等等都是系统扩展时需要考虑的因素。我们要知 道系统并发到了某一个量级之后，哪一个因素会成为我们的瓶颈点，从而针对性地进行扩展。
高并发架构演进谁不是生下来就是老司机，架构也不是架起来就支持高并发。我们来看一个经典的架构演进的例子——淘宝，真实诠释了“好的架构是进化来的，不是设计来的”。
以下是来自《淘宝技术这十年》描述的淘宝2003—2012年的架构演进。
个人网站初代淘宝的团队人员只有十来个，而且面临千载难逢的商业机会，所以要求上线的时间越快越好（实际用了不到一个月），那么淘宝的这些牛人是怎么做到的呢？
——买一个。
初代淘宝买了这样一个架构的网站： LAMP（Linux+Apache+MySQL+PHP）。整个系统的架构如下：
最后开发的网站是这样的：