对于后端服务的压测，我们的目的就是想知道当前服务能够服务的最大值。
所以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机制，原理，及语句的优化，和语句的性能分析判断。
作者：Jeson
链接：https://www.imooc.com/article/21917
来源：慕课网