单机服务器支持千万级并发长连接的压力测试
http://blog.csdn.net/lijinqi1987/article/details/74545851
应用场景
聊天室或即时消息推送系统等，因为很多消息需要到产生时才推送给客户端，所以当没有消息产生时，就需要hold住客户端的连接，这样，当有大量的客户端时，要hold住大量的长连接。
服务器配置
此处我们按照10M并发连接为目标进行配置。
一般服务器默认限制1024个文件句柄，也就是最多支持1024个并发长连接，在root用户下编辑/etc/security/limits.conf文件，修改：
·soft是一个警告值，而hard则是一个真正意义的阈值，超过就会报错。
·soft 指的是当前系统生效的设置值。hard 表明系统中所能设定的最大值
·nofile – 单进程打开文件的最大数目
·星号表示针对所有用户，若仅针对某个用户登录ID，请替换星号
这样理论上10个进程可以达到10m个并发长连接，但是在测试时会发现，并发数最多只能到达28200左右，此时，需要修改默认的本地端口范围。
linux系统端口范围为0-65536，系统提供了默认的端口范围：
故当前端口使用范围为61000-32768约为28200个，将端口范围扩大，修改/etc/sysctl.conf，增加一行：
保存，使之生效
接着在测试端程序发出的连接数量大于某个值（大概为40万时）是，通过dmesg命令查看会得到大量警告信息：[warn]socket: Too manyopenfiles in system
此时需要修改file-max，表示系统所有进程最多允许同时打开所有的文件句柄数，系统级硬限制。添加fs.file-max = 1048576到/etc/sysctl.conf中，sysctl -p保存并使之生效。
在服务端连接达到一定数量时，通过查看dmesg命令查看，发现大量TCP: toomany of orphaned sockets错误，此时需要调整tcp socket参数，添加：
net.ipv4.tcp_rmem用来配置读缓冲的大小，三个值，第一个是这个读缓冲的最小值，第三个是最大值，中间的是默认值。我们可以在程序中修改读缓冲的大小，但是不能超过最小与最大。为了使每个socket所使用的内存数最小，我这里设置默认值为4096。
net.ipv4.tcp_wmem用来配置写缓冲的大小。
读缓冲与写缓冲的大小，直接影响到socket在内核中内存的占用。
而net.ipv4.tcp_mem则是配置tcp的内存大小，其单位是页，1页等于4096字节。三个值分别为low, pressure, high
·low：当TCP使用了低于该值的内存页面数时，TCP不会考虑释放内存。
·pressure：当TCP使用了超过该值的内存页面数量时，TCP试图稳定其内存使用，进入pressure模式，当内存消耗低于low值时则退出pressure状态。
·high：允许所有tcp sockets用于排队缓冲数据报的页面量，当内存占用超过此值，系统拒绝分配socket，后台日志输出“TCP: too many of orphaned sockets”。
一般情况下这些值是在系统启动时根据系统内存数量计算得到的。 根据当前tcp_mem最大内存页面数是1864896，当内存为(1864896*4)/1024K=7284.75M时，系统将无法为新的socket连接分配内存，即TCP连接将被拒绝。实际测试环境中，据观察大概在99万个连接左右的时候(零头不算)，进程被杀死，触发outof socket memory错误（dmesg命令查看获得）。每一个连接大致占用7.5K内存（下面给出计算方式），大致可算的此时内存占用情况（990000 * 7.5/ 1024K = 7251M)。这样和tcp_mem最大页面值数量比较吻合，因此此值也需要修改。
另外net.ipv4.tcp_max_orphans这个值也要设置一下，这个值表示系统所能处理不属于任何进程的 socket数量，当我们需要快速建立大量连接时，就需要关注下这个值了。当不属于任何进程的socket的数量大于这个值时，dmesg就会看 到”too many of orphaned sockets”。
综上，服务端需要配置的内容做个汇总：
/etc/sysctl.conf 添加：
/etc/security/limits.conf 修改：
线上测试
使用ucloud云主机进行测试，服务器配置：
启动压测前系统资源情况：
使用https://github.com/yedf/handy 库自带的测试程序，进行单机并发长连接测试，该库在linux系统上使用epoll，在MacOSX上使用kqueue。
选取一台主机S作为服务器，运行服务器
选取另一台主机C作为客户端，运行客户端，（S为服务器的内网ip）
#启动10个客户端子进程，连接到S的100-300端口，发起10m个连接，在500秒内创建所有的连接，每600秒发送一个心跳，心跳数据为64字节，多进程的管理端口为301。
在服务器端使用watch ss –s 发现tcp连接数持续上升，最终稳定在4m左右
消耗资源：
系统占用了20G左右的内存，但cpu占用极少
客户端报错：
此错误一般是磁盘满导致，但是在这里是客户端在进行epoll_ctl时，内存已满导致注册epoll事件失败，所以客户端此时停止继续创建连接，可见此时的瓶颈出现在压测的客户端，如果客户端内存够用，理论上服务端10m个并发长连接应该可以实现。
说明:
单进程最大文件数量限制：ulimit -n 最多能把这个数字修改到1048575，因此单个进程最多能够打开百万个文件，千万并发连接需要千万个文件描述符，于是我们使用多进程来做到千万文件的支持。
多进程之间的负载均衡：nginx使用多进程来增加自己的吞吐量，原先采用共享锁的方式来平衡负载，对核数较多的服务器，较多的进程并没有达到性能的线性提升。最新的linux内核引入了SO_REUSEPORT选项，该选项可以自动平衡监听同一端口的多进程，是内核级的解决方案。handy采用该方案，优于nginx的旧有方式（最新的nginx也支持SO_REUSEPORT）。
测试中客户端本地端口不够：让服务器监听了200个端口，这样客户端连接服务器的每个端口只有50k个连接，然后加大默认的本地端口范围就可以满足要求（见前面的服务器系统参数）。
测试中如果一次性创建千万个连接，则绝大部分的连接创建都会失败，因此让客户端每100ms创建2000个连接，提高连接创建的成功率。