服务性能指标：PV、UV、TPS、QPS

名词解释

PV

　　Page View，网页浏览量。网页被读者调用浏览的次数。网页每次打开或刷新一次页面，记录一次。用户对同一页面的多次访问，访问量累计。

UV

　　Unique Visitor，独立访问者。是指通过互联网访问、浏览这个网页的自然人。在一定时间内，访问网站的不同访客的数量，且每个访客只被统计一次。同一个客户端的电脑，00:00~24:00访问页面多次，只计算1次。例如，假设用户周三访问3次，周四访问1次，则周三记为1次PV，周四也记为1次PV。一般通过Cookies进行计算。

TPS

　　Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。PS包括一条消息入和一条消息出，加上一次用户数据库访问。

QPS（或RPS Request Per Second）

　　Queries Per Second。每秒查询率。在规定时间内所处理流量多少的衡量标准。
　　对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。

QPS = 并发数 / 平均响应时间

系统服务端性能影响的因素

衡量服务性能的指标，主要有两个：

• QPS（Query Per Second，每秒请求数）
• 响应时间（Response Time，RT），它可以理解为服务器处理响应的耗时。

正常情况下，响应时间越短，QPS则越高。在单线程的情况下，是呈线性关系。但也不是无限增长，RT总会有极限值。

多线程时，总QPS = （1000ms/ 响应时间）* 线程数。

响应时间与QPS的关系

对于Web系统，响应时间一般由CPU的处理时间和线程的等待时间组成。

通过减少线程的等待时间，对于系统的性能提升并不是很大。真正对性能有影响的是 CPU 的执行时间。

经过实际的测试，如果减少 CPU 一半的执行时间，就可以增加一倍的 QPS。

线程数对QPS的影响

根据公式 总QPS = （1000ms/ 响应时间）* 线程数，直觉上，线程数增多QPS越高。实际上，线程数并不是越多越好。因为线程本身也占用资源，也受其他因素制约。例如，线程越多系统的线程切换成本就会越高，而且每个线程也都会耗费一定内存。（单线程语言，即使是在单台服务器上建立多个实例，也会受到服务器本身资源的限制。例如，nodeJS可以使用PM2，在一台服务器上启动多个线程，但是服务器本身资源的有限。）

如何设置合理的线程数

那么如何设置服务器上的线程数呢？通用公式如下：

线程数 = 2 * CPU核数 + 1

最佳实践的公式：

线程数 = [(线程等待时间 + 线程 CPU 时间) / 线程 CPU 时间] × CPU 数量

当然，最好的办法是通过性能测试发现系统的最佳线程数。

如何发现瓶颈

我们可以通过系统的监控工具，发现系统的性能瓶颈。通常会发生性能瓶颈的地方有CPU、内存、磁盘、网络、数据库等。

常见地，缓存系统容易发生瓶颈的地方是内存，储存型系统则是I/O。

如何简答判断CPU是否发生瓶颈了？我们可以观察，当 QPS 达到极限时，服务器的 CPU 使用率是不是超过了 95%，如果没有超过，那么表示 CPU 还有提升的空间。

性能优化的过程

1. 发现短板。
2. 减少数据。事实上，有两个地方特别影响性能。一是服务端在处理数据时不可避免地存在字符到字节的相互转化，二是 HTTP 请求时要做 Gzip 压缩，还有网络传输的耗时，这些都和数据大小密切相关。
3. 数据分级。首屏数据、重要信息优先，次级信息异步加载。
4. 减少中间环节。

附：性能测试指标

并发	响应时间	应用服务器cpu	数据库服务器cpu	TPS
50	1s	50%	20%	50

压测工具：stresstester

pom.xml文件引入包

<dependency>
    <groupId>com.taobao.stresstester</groupId>
    <artifactId>stresstester</artifactId>
    <version>1.0</version>
</dependency>

编写测试代码：

/**
* @Title: PressTest
* @Description: 压力测试，测试一下获取用户信息的方法的qps
* @param 参数
* @return void 返回类型
* @throws
*/
@Test
public void PressTest(){
    int concurrencyLevel =100;//并发数
    int totalRequest = 1000;//总请求数
    StressResult result = StressTestUtils.test(concurrencyLevel, totalRequest, new StressTask() {
    　　@Override
    　　public Object doTask() throws Exception {
       　　getUserDetail();
       　　return “”;
    　　}
　　});
    System.out.println(StressTestUtils.format(result));
}

测试结果：

　　上图测试结果很明显有问题，做长的请求3秒多，这是不能接受的，通过分析，定位到连接池设置过小，数据库连接过小，并发过大，导致请求阻塞等待资源中，优化方式：加大连接池线程数，加大数据库连接数

资料：https://mp.weixin.qq.com/s/4pjydskyaBqyjk0TDNtSVA

　　    https://www.jianshu.com/p/f38b3876f522