Web服务压测什么时候压到了服务瓶颈

幕客虽然不是专门从事测试行业，但，工作中也一直再从事着后端服务的工作，所以对于后端的压测，工作的关注度是必不可少的。

对于后端服务的压测，我们的目的就是想知道当前服务能够服务的最大值。

所以QPS 每秒的情况、TPS每秒事务、接口响应时间等等指标都是经常关注的。

大的服务网站，所关系的进度就越细。

如，淘宝、腾讯等核心接口，精度的时间单位，回到了毫秒响应了。

那么什么时候，我们的压测到了服务所能支持的最大瓶颈呢？

这个时候幕客还是想了解清楚你的目的，是上线前，想压测的你整套完整的流程。

还是只是关系你的某一部分服务性能或者你的单一一个性能接口。

假设你压测的是整个一套完整的环境，那么你需要关心：

1、客户端的情况

压测好比打群架，你用一台性能弱的机器，去压测一组集群的性能，就会鸡蛋碰石头。

客户端用多少台，什么配置的机器，甚至客户端机器的优化是往往被工程师忽略的。

2、网络情况bit/s

你的客户端和服务器是否有足量的网络带宽，能够提供压测。

所以我们需要监控网络的带宽图，这里，你需要知道：

1、带宽的链路情况

2、带宽的最大支持速率（网卡、全双工、带宽限制等等）

3、单一一次请求压测页面的字节

有了这些数据压测人员才能把控好压测的并发和频度了

3、服务端

对于服务端，我们可以聊的更多了。

（一）首先是系统：

系统是应用服务的载体，Linux系统而言，优化的方面是最基本的。

不然服务压测不上去：

压测web服务，我们应该想到的基本优化参数，如：

open files (最大打开文件) \ max user processes （最大用户进程数）等等

比较多，很多系统内核参数的调节看你系统服务模式而定（如：是长链接、短链接等等）。

（二）然后，就是应用服务了

常用的负载均衡服务：lvs、keepalive、heatbeat等

常用的代理服务有nginx、apache等

常用java容器的有tomcat，resin等

常用python的有django框架,wsgi等

常用php环境lnmp环境等等

这些都是系统工程师、或者研发所需要详细了解的。

你要知道nginx的服务特性，了解到它的内核模型epoll的实现。明白这些服务服务模式后，你才能设计很好系统架构。

然后，预估服务在各项参数调节的阀值，和性能瓶颈，了解参数作用。

如：拿nginx的upstream模块来说，你是否了解？

max_fails=3 fail_timeout=60s

又如：nginx的tcpnopush 和tcpnodeny的实现差异？

相信很多初级工程师，甚至老鸟也不一定会说明白。

（三）最后就是接口服务了

幕客觉得，这个开发很需要关心自己的接口服务频率，响应时间。

这个直接关系到，我们可以用最好的机器提供最高效的服务。

代码优化、逻辑思路的清晰、及整理的了解，对写出好的接口是有帮助的。

思路不清晰，即使就是一个查询数据库的组装的简单接口，幕客也觉得你会绕在一个地方。

不知道性能问题是在哪？

（四）还提一点，就是数据库

不要小瞧数据库管理员，数据库管理员，可不是复责加索引那么简单，或者说简单搭建数据库集群简单。

对于数据库 CURD机制，原理，及语句的优化，和语句的性能分析判断。

好了，时间不早了，幕客先介绍这些。