1 性能测试基础1.1 性能测试概述

性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

1.2 性能测试分类

性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

应用在客户端性能的测试，客户端就是压力机；当进行压力时需要监控客户端、网络端、服务端的数据。应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。

1.3 性能测试方法

并发性能测试的过程是一个基准测试、负载测试、压力测试和疲劳强度测试、稳定性测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。

基准测试：指的是模拟单个用户执行业务场景时，考察系统的性能指标。严格意义上来讲，基准测试并不能算作性能测试范畴，它跟功能测试并没有太大区别。差异在于，基准测试的目的更多地是关注业务功能的正确性，或者说验证测试脚本的正确性，然后，将基准测试时采集得到的系统性能指标，作为基准测试结果，为后续并发压力测试的性能分析提供参考依据。

负载测试：是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。目的是验证系统是否能满足预期的业务压力场景。通常负载测试是最典型的性能测试类型，通过实施负载测试来获取性能拐点，也叫最佳性能点，当达到这个点的时候，系统能力、极限能力是多少？也常用来做线上流量评估。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。

压力测试：通俗地讲，是为了发现在多大并发压力下系统的性能会变得不可接受，或者出现性能拐点（崩溃）的情况，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试，在不断增加并发压力下系统的性能会变得不可接受，出现性能崩溃的情况，计算出这时的并发值。在加压策略上，压力测试会对被测系统逐步加压，在加压的过程中考察系统性能指标的走势情况，最终找出系统在出现性能拐点时的并发用户数，也就是系统支持的最大并发用户数。

疲劳强度测试：模拟出长时间系统能承受的最大业务负载量。差异在于前两者，疲劳强度测试更关注系统在长时间运行下性能指标的变化情况。例如，系统在运行一段时间后，是否会出现事务处理失败、响应时间增长、业务吞吐量降低、CPU/内存资源增长等问题。

稳定性测试：会把用户真实会发生的场景放大3-5倍，然后在线上运行24小时，在这个阶段会发现很多稳定性问题，例如：list回收，java list回收，一旦回收出现问题，可能会出现内存溢出，这个在日常测试过程中，是很难测出来的，所以用稳定性测试查出这些问题。

1.4 性能测试目的

性能的最终目的是在保证一定的成功率、响应时间的前提下得到业务需要的最大并发数，主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。

当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候,尤其是以后在生产环境中实际使用起来,用户往往会产生疑问,这套系统能不能承受大量的并发用户同时访问? 这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。

1.5 性能测试指标

从维度上划分，性能指标主要分为两大类，分别是业务性能指标和系统资源性能指标，以下的性能指标是常用的指标，随着对性能要求的提升，需要观察其他更详细的数据，比如：其压力机和服务器的硬件也会影响性能，

1.5.1业务性能指标

ü 并发用户数：压力机模拟同时访问服务器的用户数。查看该指标目的：得到服务器最大并发用户数。

ü 事务成功率：在性能测试周期内，成功的请求数占全部请求数的百分比。查看该目标目的：服务器正确处理事务能力。

ü 事务吞吐率（TPS/RPS）：每秒服务器处理的事务数；该指标需要根据当前并发用户数、总响应时间去计算该值。查看该指标的目的：服务器处理事务的能力。

ü 事务平均响应时间：平均一条请求(事务)所用的时间。查看该目标目的：宏观查看服务器是否达到理想的并发数

ü 平均响应时间与TPS是没有直接关系，具有宏观的反比关系，随着并发数提高并超过服务器处理能力，平均响应时间就会升高，TPS则会下降。

1.5.2 资源性能指标

ü 压力机：CPU利用资源、处理器队列长度、内存利用率、磁盘IO状态、网卡带宽使用情况等；

ü 服务器：CPU利用资源、处理器队列长度、内存利用率、磁盘IO状态、网卡带宽使用情况等；

ü 数据库：数据库连接数、数据库读写响应时长、数据库读写吞吐量等；

ü 网络：网络吞吐量、网络带宽、网络缓冲池大小；

ü 缓存（Redis）：静态资源缓存命中率、动态数据缓存命中率、缓存吞吐量等；

1.6 性能测试开展流程

² 获取性能测试需求，确定性能目标

² 构建性能测试环境

² 编写性能测试脚本

² 构建性能测试场景

² 执行性能测试和分析

² 测试结果分析和报告

详见：

1.7 性能测试工具1.7.1HP Mercury LoadRunnner

这是一款历史悠久、行业地位高、市场份额大、使用广泛、功能强大的专业的性能测试工具。

1.7.2Micro Focus QALoad

这是原Compuware公司性能测试工具主打产品，如今被Micro Focus收购后任然占有一席之地，是目前业内主流的大型性能测试工具之一。

支持HTTP、HTTPS、SOAP、XML、Streaming Media、Winsock、Java、.NET、Citrix、Oracle Forms、SAP等多种协议

1.7.3Micro Focus SilkPerformer

这是原Segue公司性能测试工具的主打产品，如今被Micro Focus收购。

它是仅次于LoadRunner的大型性能测试工具，支持的协议众多，而且突出增强了对Web Service性能测试的能力，它的性能瓶颈诊断与分析功能，在某些方面比LoadRunner还强大。可与原Segue SilkCentral TestManager 和 Borland StarTeam等集成。

1.7.4Quest BenchMark Factory for Database

Quest公司的BenchMark Factory for Database 性能测试工具，它的性能测试偏向的是数据库，也是专门对数据库做性能测试和容量规划的工具。

1. 5

1.7.5JMeter

这款工具最初只是测试Web应用，最近几年发展异常迅速，到目前支持HTTP/HTTPS、SOAP、JDBC、LDAP、JMS等。当然，这些免费工具的共性就是监控、分析功能不如商业工具。

1.7.6wrk

wrk 是一款针对 Http 协议的基准测试工具，它能够在单机多核 CPU 在这条件下，使用系统自带的高性能 I/O 机制，如 epoll，kqueue 等，通过多线程和事件模式，对目标机器产生大量的负载wrk是开源的, 代码在 github：。

2 wrk用法简介

经业务测试场景与学习成本评估，本次我们选用WRK作为性能测试工具，WRK具有如下特点。

2.1 wrk优势

² 轻量级性能测试工具

² 安装简单

² 学习曲线基本为0，几分钟就学会使用了

² 基于系统自带的高性能I/O机制，如epoll，kqueue，利用异步的事件驱动框架，通过很少的线程就可以压出很大的并发量，例如几万、几十万，这是很多性能测试工具无法做到的。

2.2 wrk劣势

wrk 目前仅支持单机压测，后续也不太可能支持多机器对目标机压测，因为它本身的定位，并不是用来取代 JMeter, LoadRunner 等专业的测试工具。

2.3 格式及用法

使用方法: wrk <选项> <被测HTTP服务的URL>

Options:

-c, --connections <N> 跟服务器建立并保持的TCP连接数量

-d, --duration <T> 压测时间

-t, --threads <N> 使用多少个线程进行压测，压测时，是有一个主线程来控制我们设置的n个子线程间调度

-s, --script <S> 指定Lua脚本路径

-H, --header <H> 为每一个HTTP请求添加HTTP头

--latency 在压测结束后，打印延迟统计信息

--timeout <T> 超时时间

-v, --version 打印正在使用的wrk的详细版本信

<N>代表数字参数，支持国际单位 (1k, 1M, 1G)

<T>代表时间参数，支持时间单位 (2s, 2m, 2h)

2.4 压测结果分析

测试命令：wrk -t8 -c200 -d30s --latency

以上是使用8个线程200个连接，对bing首页进行了30秒的压测，并要求在压测结果中输出响应延迟信息。

关于线程数，并不是设置的越大，压测效果越好，线程设置过大，反而会导致线程切换过于频繁，效果降低，一般来说，推荐设置成压测机器 CPU 核心数的 2 倍到 4 倍就行了。标准差啥意思？标准差如果太大说明样本本身离散程度比较高，有可能系统性能波动较大。

Running 30s test @ （压测时间30s）

8 threads and 200 connections （共8个测试线程，200个连接）

（平均值） （标准差）（最大值）（正负一个标准差所占比例）

Thread Stats Avg Stdev Max +/- Stdev

（延迟）

Latency 46.67ms 215.38ms 1.67s 95.59%

（处理中的请求数）

Req/Sec 7.91k 1.15k 10.26k 70.77%

Latency Distribution （延迟分布）

50% 2.93ms

75% 3.78ms

90% 4.73ms

99% 1.35s （99分位的延迟：%99的请求在1.35s以内）

1790465 requests in 30.01s, 684.08MB read （30.01秒内共处理完成了1790465个请求，读取了684.08MB数据）

Requests/sec: 59658.29 （平均每秒处理完成59658.29个请求）

Transfer/sec: 22.79MB （平均每秒读取数据22.79MB）

2.5 高级用法

使用lua脚本进行压测，lua脚本是一种轻量小巧的脚本语言，用标准c语言编写，并以源代码形式开放，其设计目的是为了嵌入应用程序中，从而为程序提供灵活的扩展和定制功能。wrk工具嵌入了lua脚本语言，因此，在自定义压测场景时，可在wrk目录下使用lua定制压测场景。

自定义脚本中可访问的变量和方法：

wrk = {   //变量：wrk

    scheme  = "http",

    host    = "localhost",

    port    = nil,

    method  = "GET",

    path    = "/",

    headers = {},

    body    = nil,

    thread  = <userdata>,

  }

方法：wrk.fomat wrk.lookup wrk.connect

function wrk.format(method, path, headers, body)  --根据参数和全局变量wrk，生成一个HTTP rquest string。

function wrk.lookup(host, service)  --给定host和service（port/well known service name），返回所有可用的服务器地址信息。

function wrk.connect(addr)  --测试与给定的服务器地址信息是否可以成功创建连接

2.5.1 lua脚本压测实例

压测命令：wrk -t8 -c200 -d30s --latency -s test.lua

test.lua是用lua写的压测脚本，如下是压测脚本的实例：

使用post方法压测

wrk.method = "POST"

wrk.headers["S-COOKIE2"]="a=2&b=Input&c=10.0&d=20191114***"

wrk.body = "recent_seven=20191127_32;20191128_111"

wrk.headers["Host"]="api.shouji.**.com"

function response(status,headers,body)

        if status ~= 200 then --将服务器返回状态码不是200的请求结果打印出来

                print(body)

        --      wrk.thread:stop()

        end

end

 发送json

request = function()

    local headers = { }

    headers['Content-Type'] = "application/json"

    body = {

        mobile={"1533899828"},

        params={code=math.random(1000,9999)}

    }

    local cjson = require("cjson")

    body_str = cjson.encode(body)

    return wrk.format('POST', nil, headers, body_str)

end

wrk读取文件，实现随机header-cookie

idArr = {}

falg = 0

wrk.method = "POST"

wrk.body = "a=1"

function init(args)

        for line in io.lines("integral/cookies.txt") do

                print(line)

                idArr[falg] = line

                falg = falg+1

        end

        falg = 0

end

--wrk.method = "POST"

--wrk.body = "a=1"

--wrk.path = "/v1/points/reading"

request = function()

        parms = idArr[math.random(0,4)] --随机传递文件中的参数

        --parms = idArr[falg%(table.getn(idArr)+1)] 循环传递文件中的参数

        wrk.headers["S-COOKIE2"] = parms

        falg = falg+1

        return wrk.format()

end

wrk创建数组并初始化，拼接随机参数

idArr = {};

function init(args)

        idArr[1] = "1";

        idArr[2] = "2";

        idArr[3] = "3";

        idArr[4] = "4";

end

request = function()

        parms = idArr[math.random(1,4)]

        path = "/v1/points/reading?id="..parms

        return wrk.format("GET",path)

end

系统优化除了CPU、网络、磁盘IO，内存等硬件支撑外，内核参数优化尤为重要，Linux服务器内核参数优化（适合Apache、Nginx、Squid等多种web应用，特殊的业务有可能需要做略微调整），主要是指在Linux系统中针对业务服务应用而进行的系统内核参数调整，优化并无一定的标准。下面是生产环境下Linux常见的内核优化为例子进行说明，供大家参考。

vi /etc/sysctl.conf //编辑配置文件

sysctl –p //使配置生效

net.core.netdev_max_backlog = 400000

net.core.optmem_max = 10000000

net.core.rmem_default = 10000000

net.core.rmem_max = 10000000

net.core.somaxconn = 65535

net.core.wmem_default = 11059200

net.core.wmem_max = 11059200

net.ipv4.conf.all.rp_filter = 1

net.ipv4.conf.default.rp_filter = 1

net.ipv4.tcp_congestion_control = bic

net.ipv4.tcp_window_scaling = 0

net.ipv4.tcp_ecn = 0

net.ipv4.tcp_sack = 1

net.ipv4.tcp_max_tw_buckets = 10000

net.ipv4.tcp_max_syn_backlog = 8192

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_timestamps = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_fin_timeout = 10

net.ipv4.tcp_keepalive_time = 1800

net.ipv4.tcp_keepalive_probes = 3

net.ipv4.tcp_keepalive_intvl = 15

net.ipv4.tcp_wmem = 30000000 30000000 30000000

net.ipv4.ip_local_port_range = 1024 65000

net.ipv4.tcp_slow_start_after_idle = 0

net.ipv4.route.gc_timeout = 100

net.ipv4.tcp_syn_retries = 1

net.ipv4.icmp_echo_ignore_broadcasts = 1

net.ipv4.icmp_ignore_bogus_error_responses = 1

net.ipv4.conf.default.accept_source_route = 0

#以下参数是对iptables防火墙的优化，防火墙不开会提示，可以忽略不理

net.nf_conntrack_max = 25000000

net.netfilter.nf_conntrack_tcp_timeout_established = 180

net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120

net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60

net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120

3.2 Web中间件优化3.2.1 Nginx优化

一般来说nginx 配置文件中对优化比较有作用的为以下几项：

1. worker_processes 8;

nginx 进程数，建议按照cpu 数目来指定，一般为它的倍数 (如,2个四核的cpu计为8)。

2. worker_rlimit_nofile 65535;

这个指令是指当一个nginx 进程打开的最多文件描述符数目，理论值应该是最多打开文

件数（ulimit -n）与nginx 进程数相除，但是nginx 分配请求并不是那么均匀，所以最好与ulimit -n 的值保持一致。

3．use epoll;

使用epoll 的I/O 模型

4.worker_connections 65535;

每个进程允许的最多连接数， 理论上每台nginx 服务器的最大连接数为worker_processes*worker_connections。

5.keepalive_timeout 60;

keepalive 超时时间。

6. client_header_buffer_size 4k;

客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求头的大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。

7.open_file_cache max=65535 inactive=60s;

这个将为打开文件指定缓存，默认是没有启用的，max 指定缓存数量，建议和打开文件数一致，inactive 是指经过多长时间文件没被请求后删除缓存。

8. open_file_cache_valid 80s;

这个是指多长时间检查一次缓存的有效信息。

9. open_file_cache_min_uses 1;

open_file_cache 指令中的inactive 参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive 时间内一次没被使用，它将被移除。

3.2.1.1优化实例

worker_processes auto;

worker_rlimit_nofile 100000;

events {

worker_connections 65535;

multi_accept on;

use epoll;

}

3.2.2 tomcat优化

1、 修改内存等 JVM相关配置

Linux下修改TOMCAT_HOME/bin/catalina.sh

JAVA_OPTS="-server -XX:PermSize=512M -XX:MaxPermSize=1024m -Xms2048m -Xmx2048m

windows下修改TOMCAT_HOME/bin/catalina.bat

set JAVA_OPTS=-server -XX:PermSize=512M -XX:MaxPermSize=1024m -Xms2048m -Xmx2048m

时区优化

JAVA_OPTS="$JAVA_OPTS -Djava.protocol.handler.pkgs=org.apache.catalina.webresources -Duser.timezone=GMT+08"

参数说明：

-server：启用 JDK的 server 版本；

-Xms：Java虚拟机初始化时堆的最小内存，一般与 Xmx配置为相同值，这样的好处是GC不必再为扩展内存空间而消耗性能；

-Xmx：Java虚拟机可使用堆的最大内存；

-XX:PermSize：Java虚拟机永久代大小；

-XX:MaxPermSize：Java虚拟机永久代大小最大值；

Ø 错误提示：java.lang.OutOfMemoryError:Java heap space

Tomcat默认可以使用的内存为128MB，在较大型的应用项目中，这点内存是不够的，有可能导致系统无法运行。常见的问题是报Tomcat内存溢出错误，Outof Memory(系统内存不足)的异常，从而导致客户端显示500错误，一般调整Tomcat的-Xms和-Xmx即可解决问题，通常将-Xms和-Xmx设置成一样，堆的最大值设置为物理可用内存的最大值的80%。

set JAVA_OPTS=-Xms512m-Xmx512m

Ø 错误提示：java.lang.OutOfMemoryError: PermGenspace

PermGenspace的全称是Permanent Generationspace,是指内存的永久保存区域，这块内存主要是被JVM存放Class和Meta信息的,Class在被Loader时就会被放到PermGenspace中，它和存放类实例(Instance)的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGenspace进行清理，所以如果你的应用中有很CLASS的话,就很可能出现PermGen space错误，这种错误常见在web服务器对JSP进行precompile的时候。如果你的WEB APP下都用了大量的第三方jar, 其大小超过了jvm默认的大小(4M)那么就会产生此错误信息了。解决方法：

setJAVA_OPTS=-XX:PermSize=128M

Ø 在使用-Xms和-Xmx

调整tomcat的堆大小时，需要考虑垃圾回收机制。如果系统花费很多的时间收集垃圾，请减小堆大小。一次完全的垃圾收集应该不超过3-5 秒。如果垃圾收集成为瓶颈，那么需要指定代的大小，检查垃圾收集的详细输出，研究垃圾收集参数对性能的影响。一般说来，应该使用物理内存的 80% 作为堆大小。当增加处理器时，记得增加内存，因为分配可以并行进行，而垃圾收集不是并行的。

2、Connector 优化

Connector是连接器，负责接收客户的请求，以及向客户端回送响应的消息。所以 Connector的优化是重要部分。默认情况下 Tomcat只支持200线程访问，超过这个数量的连接将被等待甚至超时放弃，所以我们需要提高这方面的处理能力。

参数说明：

maxThreads 客户请求最大线程数

minSpareThreads Tomcat初始化时创建的 socket 线程数

maxSpareThreads Tomcat连接器的最大空闲 socket 线程数

enableLookups 若设为true, 则支持域名解析，可把 ip 地址解析为主机名

redirectPort 在需要基于安全通道的场合，把客户请求转发到基于SSL 的 redirectPort 端口

acceptAccount 监听端口队列最大数，满了之后客户请求会被拒绝（不能小于maxSpareThreads ）

connectionTimeout 连接超时

minProcessors 服务器创建时的最小处理线程数

maxProcessors 服务器同时最大处理线程数

URIEncoding URL统一编码

2、 缓存优化

参数说明

compression 打开压缩功能

compressionMinSize 启用压缩的输出内容大小，这里面默认为2KB

compressableMimeType 压缩类型

connectionTimeout 定义建立客户连接超时的时间. 如果为 -1, 表示不限制建立客户连接的时间

3、 使用线程池

在server.xml中增加executor节点，然后配置connector的executor属性，如下：

<Executor name="tomcatThreadPool" namePrefix="req-exec-"maxThreads="1000" minSpareThreads="50"maxIdleTime="60000"/>

<Connector port="8080" protocol="HTTP/1.1"executor="tomcatThreadPool"/>

参数说明

namePrefix：线程池中线程的命名前缀

maxThreads：线程池的最大线程数

minSpareThreads：线程池的最小空闲线程数

maxIdleTime：超过最小空闲线程数时，多的线程会等待这个时间长度，然后关闭

threadPriority：线程优先级

4、 NIO模式

Ø BIO：一个线程处理一个请求。缺点：并发量高时，线程数较多，浪费资源。Tomcat7或以下在Linux系统中默认使用这种方式。

Ø NIO：利用Java的异步IO处理，可以通过少量的线程处理大量的请求。Tomcat8在Linux系统中默认使用这种方式。Tomcat7必须修改Connector配置来启动（conf/server.xml配置文件）：

<Connector port="8080"protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000"redirectPort="8443"/>

Ø APR(Apache Portable Runtime)：从操作系统层面解决io阻塞问题。Linux如果安装了apr和native，Tomcat直接启动就支持apr。

3.2.2.1优化实例

<Connector port="8080" protocol="HTTP/1.1"

connectionTimeout="20000"

maxThreads="1000"

minSpareThreads="100"

maxSpareThreads="1000"

minProcessors="100"

maxProcessors="1000"

enableLookups="false"

URIEncoding="utf-8"

acceptCount="1000"

redirectPort="8443"

compression="on"

compressionMinSize="2048"

compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"

disableUploadTimeout="true"

maxPostSize="-1"

maxHttpHeaderSize="8192"

/>

protocol=”org.apache.coyote.http11.Http11NioProtocol” ，表示以 NIO模式启动。

3.3 数据库优化

选项

默认值

说明

是否优化

原因

max_connections

100

允许客户端连接的最大数目

超过2000报错时：执行

echo 250 250000 32 1000 >/proc/sys/kernel/sem

sysctl -p

修改max_connection = 10000

是

1500

最大连接数= used_connections/max_connections在85%左右

连接池数 = ((核心数 * 2) + 有效磁盘数)

fsync

on

强制把数据同步更新到磁盘

是

因为系统的IO压力很大，为了更好的测试其他配置的影响，把改参数改为off

shared_buffers

24MB

决定有多少内存可以被PostgreSQL用于缓存数据（推荐内存的1/4)

是

在IO压力很大的情况下，提高该值可以减少IO

work_mem

1MB

使内部排序和一些复杂的查询都在这个buffer中完成

是

有助提高排序等操作的速度，并且减低IO

effective_cache_size

128MB

优化器假设一个查询可以用的最大内存，和shared_buffers无关（推荐内存的1/2)

是

设置稍大，优化器更倾向使用索引扫描而不是顺序扫描

maintenance_work_mem

16MB

这里定义的内存只是被VACUUM等耗费资源较多的命令调用时使用

是

把该值调大，能加快命令的执行

wal_buffer

768kB

日志缓存区的大小

是

可以降低IO，如果遇上比较多的并发短事务，应该和commit_delay一起用

checkpoint_segments

3

设置wal log的最大数量数（一个log的大小为16M）

是

默认的48M的缓存是一个严重的瓶颈，基本上都要设置为10以上

checkpoint_completion_target

0.5

表示checkpoint的完成时间要在两个checkpoint间隔时间的N%内完成

是

能降低平均写入的开销

commit_delay

0

事务提交后，日志写到wal log上到wal_buffer写入到磁盘的时间间隔。需要配合commit_sibling

是

能够一次写入多个事务，减少IO，提高性能

commit_siblings

5

设置触发commit_delay的并发事务数，根据并发事务多少来配置

是

减少IO，提高性能

autovacuum_naptime

1min

下一次vacuum任务的时间

是

提高这个间隔时间，使他不是太频繁

autovacuum_analyze_threshold

50

与autovacuum_analyze_scale_factor配合使用，来决定是否analyze

是

使analyze的频率符合实际

autovacuum_analyze_scale_factor

0.1

当update,insert,delete的tuples数量超过autovacuum_analyze_scale_factor*table_size+autovacuum_analyze_threshold时，进行analyze。

是

使analyze的频率符合实际

timezone

Asia/Shanghai

数据库时区，看情况是否需要修改成和jvm或本地时间一致，否则用数据库函数生成的时间不对应

3.4测算标准先使用单线程不断增加连接数，直到QPS保持稳定或响应时间超过业务要求限制。在当期数值取得单线程最优连接数。单个连接线程数保持不变，不断增加线程数(建议到CPU核心数为止即可)，直到整体出现QPS水平。如果QPS没有出现随着线程数增长则是目标服务器性能已经达到瓶颈，wrk单线程即可压测出目标机器最优QPS。如果QPS一直没有出现水平趋势，则说明wrk压测机性能出现了瓶颈，需要扩大wrk压测机性能或者增加压测机器集群。

QPS:每秒查询率（Query Per Second），每秒的响应请求数，也即是最大吞吐能力。

QPS = rep/sec = 请求数/秒

QPS 统计方式【一般使用http_load进行统计】

QPS = 总请求数 / (进程总数 *请求时间)

QPS: 单个进程每秒请求服务器的成功次数

峰值 QPS:

每天80% 的访问集中在 20% 的时间里，这 20% 的时间叫做峰值时间

公式：（总 pv 数 * 80%）/ (每天秒数 * 20%) = 峰值时间每秒请求数据（QPS）

PV:访问量即 Page View，即页面浏览量或点击量，用户每次刷新即被计算一次单台服务器每天 PV 计算

公式1：每天总 PV = QPS * 3600 * 6

公式2：每天总 PV = QPS * 3600 * 8

UV:独立访客即 Unique Visitor，访问您网站的电脑哭护短为一个访客，00:00-24:00 内相同的客户端只被计算一次服务器数量

机器：峰值时间每秒 QPS / 单台机器的 QPS = 需要的机器

机器:ceil (每天总 PV / 单台服务器每天总 PV)

并发数：并发用户数是指系统可以同时承载的这正常使用系统功能的要用户的数量

吞吐量：吞吐量是指系统在单位时间内处理的请求的数量

响应时间（RT）：响应时间是指系统对请求作出的响应的时间

例子：每天 300w PV 的在单台机器上，这太机器需要多少 QPS?

答：（3000000 * 0.8） / （86400 * 0.2）= 139(qps)

如果一台机器的QPS 是 58 ,需要几台机器？

139/58 = 3

3.4测试案例

post application/json

./wrk -c200 -t8 -d30s -s c_login.lua --timeout=5s --latency

wrk.method = "POST"

wrk.headers["Content-Type"] = "application/json"

wrk.body = '{"password":"test","username":"test"}'

post application/x-www-form-urlencoded

./wrk -c200 -t8 -d30s -s c_query.lua --timeout=5s --latency

wrk.method = "POST"

wrk.headers["Authorization"] = "test"

wrk.headers["Content-Type"] = "application/x-www-form-urlencoded;charset=UTF-8"

wrk.body = 'page=page:{"pageNo":1,"pageSize":50}&startDate=2016-02-29 00:00:00&endDate=2021-06-30 23:59:59'