phpqps技巧_阿弟从300qps至3000qps的优化之路

原文链接：http://www.postgres.cn/news/viewone/1/283原作者：阿弟 创作韶光：2017-08-16 23:40:18

现在的并发文章动不动就系统架构，虚得弗成。
网友阿弟写的这篇反而从零开始步步实操，是篇好文章，相称值得借鉴

一个车货匹配项目，初步估计有100万司机。
支持每秒500次查询最新货源列表，业务高峰时每分钟大约10万司机（包括大量无注册司机）在线查询最新的货源订单。
即1500qps，当然还有很多低频率的业务，如每秒几笔货源订单。

环境准备: 测试资源是线下开拓机，非生产环境

数据库做事器

CPU：至强 4核 单线程

RAM：32G

硬盘：7200转SAS 1T 2个做了raid1

OS：Centos 6.4

网卡：1000M

IP：192.168.1.6

运用做事器

CPU：至强 4核 单线程

RAM：32G

硬盘：7200转SAS 1T 2个做了raid1

OS：Centos 7.0

网卡：1000M

IP：192.168.1.10

交流机

H3C 1000M

平台初步技能方案

基于公司目前技能储备，我们可以选择利用的组件有nginx/apache/php/go/pgbouncer/pg,这些组件可以组合的架构还是很丰富的，原则上能知足业务需求的情形下，架构是越大略越好。
繁芜的架构出问题的机率越高

但很明显，全体系统的瓶颈肯定是在各种Api与数据库通信这一环节上面,这是优化的重中之重

PostgreSQL 9.4.1、nginx-1.6.2、apache-2.2.31、php-5.5.38、pgbouncer-1.5.4、golang-1.7.3

1、PostgreSQL 9.4.1

编译安装

初始化

参数配置

其它参数全部先默认

2、apache-2.2.31

编译安装

选择worker-mpm模式

参数配置

其它参数全部先默认

3、php-5.5.38

编译安装

参数配置

4、nginx-1.6.2

编译安装

参数配置

5、pgbouncer-1.5.4

pgbouncer连接池也装在运用做事器上面

编译安装

安装pgbouncer须要libevent包

参数配置

运行参数文件/home/ad/pgbouncer/pgbouncer.ini

用户及口令文件/home/ad/pgbouncer/user.txt

6、golang-1.7.3

直接安装

测试数据及脚本

1、数据库环境

2、测试程序

1、apache+php

短连接测试

配置apache,关闭长连接配置

重启做事

在其余一台电脑上利用wrk工具进行测试

利用atop查看做事器的资源利用情形

http连接断开等待情形

长连接测试

非全程长连接

跑wrk测试

利用atop查看做事器的资源利用情形

全程长连接

跑wrk测试

利用atop查看做事器的资源利用情形

从上面测试的结果来看，在高并发，高压力的情形下，进程复用可以提高一倍的系统性能。
短连接时产生了大量的TIME_WAIT进程，产生的缘故原由紧张是客户端不断的连接和断开，在高并发的情形下，做事器迟迟没收到客户端断开连接的第四次握手旗子暗记造成的，这些进程会一贯占用locale port, 导致本地端口号给花费光了。
可以设置下面的内核参数来提高locale port的利用效率

net.ipv4.tcp_syncookies = 1 #表示开启SYN Cookies,可戒备少量SYN攻击，默认为0

net.ipv4.tcp_tw_reuse = 1 #许可将TIME-WAIT sockets重新用于新的TCP连接，默认是0

net.ipv4.tcp_tw_recycle = 1 #表示开启TCP连接中TIME-WAIT sockets的快速回收，默认是0

net.ipv4.ip_local_port_range = 1024 65535 #增大locale port数量，默认是从32768开始

不过这几个参数是治标不治本，终极还是要回到提升api本身的处理能力.其余对付动态的api接口业务，如果你的客户端直接与apache进行通信，现实中基本都是短连接业务，以是用apache+php跑个13000已经是极限了。

2、nginx+apache+php

nginx与apache短连接通信

下面我们来看看nginx+apache+php在短连接的情形下，locale port是若何给花费光的，nginx+apache+php见上面的配置

利用wrk工具对nginx进行压力测试

利用atop查看做事器的资源利用情形

在测试到一半的时候再打开一个终端，测试一下做事器是否还有接管要求的能力，创造连接超时，利用top查看系统负载情形，竟然没负载

1871次/秒的处理能力，还有timeout情形，是不是疑惑nginx有问题，实在这不是nginx的问题，紧张是nginx处理能力太强了，而apache跑php弱了，导致进程一贯占用socket port,我们只须要做一下这样的调度，做事器的处理能力就上来了

nginx与apache长连接通信

利用atop查看做事器的资源利用情形

客户端与nginx长连接通信，nginx与apache长连接通信

看上去数据变革不大，但是TIME_WAIT量明显减少了

由于nginx和apache是跑在同一个节点上，cpu相互争用，以是并发数下来，如果跑在不同的机器上，nginx代理的损耗实在是非常小的，看看下面的测试就会知道

nginx与apache长连接通信（不同节点）

nginx位于运用做事器

apache位于数据库做事器

从上面的测试数据来看，建议高并发大略业务的接口采取第5种方案，如果是web网页与接口稠浊利用的，利用第6种模式

为了测试更靠近于实际业务场景，这次利用http_load工具，http_load利用单进程并发多个线程进行并发测试，访问nginx时采取的是非长连接访问，并且可以设置每秒访问接口次数，http_load测试特殊解释

单进程限定每秒1000次访问

参数为-r 334（超过1000的三分之一）时，实际上能跑到500次/秒的访问量

参数为-r 501（超过1000的二分之一）时，测试端cpu会跑满

以是跑每秒500次访问时参数是-r 334, 跑每秒1000次访问时启用两个-r 334 http_load进程来测试，依此类推

仿照每秒100次访问，持续访问300秒

仿照每秒500次访问，持续访问300秒

由于测试工具占用cpu资源还是比较大，须要其余一台主机上运行，这样测试更准确

1、nginx+apache+php+pgsql

测试结果

每秒100次访问

其它略，下面是测试结果比拟表

数据库做事器压力比拟

运用做事器压力比拟

从上面的数据来看，qps为400时数据库做事器就涌现了不稳定情形，而且运用做事器的locale port会被花费光。
通过对数据的比拟，创造数据库做事器sys_cpu比user_cpu占用量还要大，缘故原由与上面运用做事性能测试时同等，便是在高并发时，进程不断连接和关闭过度花费了cpu资源。
运用做事器locale port给占完，导致http要求失落败。
得想办法让运用程序与pg做事连接进程可以复用，减少数据库做事器的cpu压力才行，上pgbouncer连接池吧。

下面先说一下，若何查询pg进程有没复用，利用捉包工具tcpdump捉取两次独立要求时连接数据库的local port ，如port同等则便是进程复用，如下所示

在数据库做事器上的一个终端输入下面命令

在测试机上连续输入下面命令二次，非连接池连接

在tcpdump终端你会看到下面的信息，对应的locale port不一致

在测试机上连续输入下面命令二次，连接池连接

在tcpdump终端你会看到下面的信息，对应的locale port同等

2、nginx+apache+php+pgbouncer+pgsql

每秒100次访问

其它略，下面是测试结果比拟表

数据库做事器压力比拟

运用做事器压力比拟

从上面的数据来看，qps为400时数据库做事器压力非常的小，但运用做事器与数据库做事器的通信效率太低，导致运用做事器的locale port被花费光，http做事谢绝连接，瓶颈在运用与连接池的通信效率上，只能水平扩展多一些运用做事器节点了，

下面看看双运用做事器节点的性能是不是会提高

3、nginx负载双节点(apache+php)+pgbouncer+pgsql

nginx.conf配置如下

首先在数据库节点上也装上apache/php/pgbouncer

接着修正运用节点上的nginx.conf配置，如下

重启nginx做事

测试开始

每秒100次访问

其它略，下面是测试结果比拟表

运用做事器压力比拟

从上面的数据来看，运用做事器水平扩展之后，并发数也随着上来了，而且数据库做事器的压力还是在可以接管的范围之内，虽然知足了业务的初步要求，但还是无法对付峰值要求，如果想处理更大的并发量，要不再水平扩展运用做事器，另一个便是想办法提高“运用程序与pg”的通信效率，下面利用go来实现这些架构，看看是不是会提高。

4、基于go的后端做事架构

这是go的做事端程序

启动做事，配置8个连接数

测试开始

每秒100次访问

其它略，下面是测试结果比拟表

数据库做事器压力比拟

运用做事器压力比拟

从上面的测试数据我们可以看到基于go的做事端运用程序由于每次处理业务时都不须要与运用程序进行通信，也不须要与数据库进行连接，以是其sys cpu花费的极其的低，编译型程序，实行效率也高，在并发到3000的qps时，数据库的cpu负载才过一半。
由此可见利用Go做事端运用来支撑业务大略的高并发运用是非常适宜的方案。

为了更友好的对外通信，统一api入口，我们利用nginx做web做事入口，再代理跑各种运用，现在来看看nginx代理跑go性能是否也能知足

5、基于nginx+go的后端做事架构

nginx上的配置，记得配置nginx与go通信采取长连接哦

下面是测试结果比拟表

数据库做事器压力比拟

运用做事器压力比拟

加了nginx代理之后对数据库的性能没影响，只是运用做事器的cpu开销大了一点，这个损耗是在可接管范围之内的，而且也可以将nginx与运用做事节点进行分离到不同的节点上面。

各种框架处理qps峰值－－值越大越好

各种框架处理300qps时cpu压力－－值越小越好

以上是对付高并发，业务极其大略的接口在通信架构上的一种优化办法，详细采取哪种构架来搭建你们的运用，须要详细业务详细优化，灵巧搭配便是，其余还要考虑运维的本钱。

作者：阿弟来源：掘金商业用场请与原作者联系，本文只做展示分享，欠妥侵删！