常用的工具
jmeter，loadrunner，locust
并发数
并发数是指在同一个时间点，同时请求服务的客户数量。
比如大家常说的：『 我的网站可以承受一万并发。 』在通常情况下指的是：如果同时有一万名用户访问网站，所有人都可以正常获得服务。而不会有超时或连接拒绝情况发生。
吞吐率
吞吐率指的是服务处理请求的效率，计算方式为 （ 总处理请求数 / 总耗时 ）。
HTTP 服务的吞吐率通常以 RPS（Requests Per Second 请求数每秒）作为单位。吞吐量越高，代表服务处理效率就越高。换句话说就是网站的性能越高。
注意：吞吐率和并发数是两个完全独立的概念。拿银行柜台来举个例子，并发数指同时有多少人往银行柜台涌来。吞吐率则指银行柜台在一段时间内可以服务多少个人。
但是在性能测试中，二者之间通常会呈现出一种关联关系。当并发数增大时，吞吐率通常也会随之上升（ 多用户发挥出并行处理优势） 。但在并发数超过某个边界值后，吞吐率则会下降 （用户过多，花在上下文切换的开销急剧增大，又或者内存消耗过多）。
响应时间
响应时间指的是用户从发出请求到接收完响应之间的总耗时，它由网络传输耗时、服务处理耗时等多个部分组成。通常以毫秒（ms）作为单位。
与并发数的关系：一般来说，随着并发数增大，单个用户的响应时间通常会随之增加。这很好理解，餐馆吃饭的人越多，单个顾客等待的时间就越长。
与吞吐率的关系：更高的吞吐率通常意味着更低的响应时间。因为吞吐率是以 单位时间 内的请求处理能力来计算的。
平均响应时间与百分位响应时间
平均响应时间指的是所有请求平均花费的时间，如果有100个请求，其中 98 个耗时为 1ms，其他两个为 100ms。那么平均响应时间为 (98 * 1 + 2 * 100) / 100.0 = 2.98ms 。
百分位数（ Percentile - Wikipedia ）是一个统计学名词。以响应时间为例， 99% 的百分位响应时间 ，指的是 99% 的请求响应时间，都处在这个值以下。
拿上面的响应时间来说，其整体平均响应时间虽然为 2.98ms，但 99% 的百分位响应时间却是 100ms。
相对于平均响应时间来说，百分位响应时间通常更能反映服务的整体效率。现实世界中用的较多的是 98% 的百分位响应时间，比如 GitHub System Status 中就有一条 98TH PERC. WEB RESPONSE TIME 曲线。
平均响应时间： 所有请求的平均响应时间，取的平均值
95%percentile ： 统计学术语，如果将一组数据从小到大排序，并计算相应的累计百分位，则某一百分位所对应数据的值就称为这一百分位的百分位数。可表示为：一组n个观测值按数值大小排列。如，处于p%位置的值称第p百分位数。
例如有100个请求， 每个请求的响应时间分别是 1-100 平均分布
平均响应时间： 1-100 的平均值，即 50.5
95% percentile ： 按从小到大排序，累计第95百分位，也就是 95 （即样本里95% 的数据都不高于这个值）
影响性能的原因
硬件当然是内存越大越好，CPU同样也是，宽带要选择大流量，CDN加速，二级域名之类的都能优化性能。
前台要控制同一用户的某个接口访问次数，简单的来说就是防止用户多次点按钮去重复访问造成流量浪费。
从一个服务器角度来说，从线程池里获取线程到执行完将线程返回到线程池过程为一个请求，这里面有影响的首先就是线程池的大小，核心线程数越大，性能就越好，若实际情况尽量不要超过最大线程数。
JVM和硬件十分相关，需要根据实际情况进行调整，其他连接如redis连接，数据库连接，同样都要注意连接池的配置，以及资源释放问题，之前遇到一些连接释放失败的bug导致服务器的性能越来越差。
从架构上来讲，后台的集群数量，主从配置的模式等等更加影响性能，实际中不同业务对应不同的后台集群服务，大多数情况都是根据业务配置不同数量的服务器。
实际背景
做项目开发的时候，不止一次被性能测试问“这个服务性能要求是多少？”他期望能得到一个这次接口TPS压到50还是100，返回时间是100ms还是200ms的回答。然后压力测试的脚本就跑起来，挨个接口就去压了。
但作为产品我怎么知道报多少合适呢？（是的，在某些团队这是研发负责人应该考虑的）。通常我们是只知道业务量，怎么转换成tps、返回时间的要求呢？（有时候业务量都估算不出来，那这种场景下你就按最顶部的推荐的来测吧。）
现在，只要10分钟，让你了解怎么计算这些内容。
首先，需要知道不同的产品有不同的应对要求
手机发货的抢购秒杀场景和美团的场景需求不一致，导致产品性能要求就不一致
千万级用户的app和十万级app，同样的性能要求，转换为技术指标上也不一致
继续计算，我们需要了解
什么是TPS
Transactions Per Second（每秒传输的事物处理个数，或者说每秒系统接收的任务数量），系统接收到任务后会有一个处理时间。
在压力测试时，测试人员会主动按一定tps的量来主动发起接口请求，比如tps=50，就是每秒请求50次，获取一个平均的响应时间（单位一般都是毫秒ms）。压力测试人员口中的TPS50 200ms返回，就是指每秒测试人员主动发起50次请求，这些请求会在平均200ms返回。
由于其他技术指标如QPS（数据的每秒查询个数）等性能都会在tps这个维度上展示出来，因此可通过tps对系统性能进行简单判断，以满足日常性能测试需求。
性能测试的指标是怎么来的呢？
1、产品和运营要给出业务匡算：
这个服务，在多长时间段，多少人会访问
2、性能要求上，通常情况下的APP应该如何？
页面访问的2、5、8原理（用户进入服务2s内要展示完所有内容，超过5秒用户就无法忍受了，超过8秒就没有人再等了，直接关闭服务）
因此页面的渲染时间+资源文件的载入时间+接口的获取时间需要保证1s~2s内完成
3、这个条件下接口获取时间多长合适？
无脑建议200ms以内（考虑到你页面也要2s打开，还要给其他工作留时间）
怎么通过业务量来计算TPS多少合适呢？
直接上公式不太好理解，我们先看案例
案例1，秒杀型算法
案例的业务量要求
某业务，类似秒杀型，用户估算有2W左右，每个用户平均请求2次接口（查询用户信息接口、查询业务接口）， 这些用户大概率会在2分钟内会访问我们的系统，业务要保证用户2s能打开页面
TPS的分析
TPS是系统每秒钟处理的任务数量，给定二业务场景，我们就需要先计算出来每秒需要系统处理多少任务，从而反推在压力测试的时候，需要给多大的TPS了。
首先，整个系统的总请求数=用户（2W）* 每个用户请求数（2次）= 40000次
其次，每秒要求处理的请求数=总请求数/时间（切换到秒） 即约350（333向上取个整吧）。
最后，TPS并发数量与每个请求所消耗的时间，可实际计算出每秒实际能够处理的请求数。
即每秒实际处理请求数量=tps数量 * 1000【1秒，需要切换为毫秒】/单组tps处理时间【这里是按200ms返回】
因此，我们只要保证 每秒实际处理请求数>每秒要求处理的请求数 就可以了。
最终结果
TPS数量 > 每秒要求处理的请求数 * tps返回时间【按200ms计算】/1000ms
带入数据计算
tps>(350 * 200)/1000，具体tps>70。
因此可让压力测试人员按照tps100来压接口，返回在200ms以内就满足性能要求。
当然如果实际tps50的返回时间为100ms，则按照这个粗略的公式来推算，也是能够支撑的（350 * 100/1000=35，也就是说tps高于35，返回100ms以内也是可以的）
案例2，我们来看一个日常服务的算法
如：一个100w访问的服务，每天访问集中白天8小时，每个用户大约会请求3个接口，每天早上9点是峰值。
首先计算日均请求数（每秒）
按8小时 100w访问量、平均3个接口请求计算
每秒日均请求数=100w（访问量）* 3（每个访问量平均请求接口数）/8（小时）/3600（切换成秒），结果就是每秒请求100次。
按接口200ms返回，tps需要> 100 * 200/1000，即>20就行了。
如考虑日常服务的峰值，则按4 * 日均，即每秒请求400次，则tps>80即可，因此可推荐按tps=100来做接口的压力测试。
相关总结
时间段越短，数据也越接近于瞬间并发
如果用整日的数据来计算总请求数，需要按照日流量分布来估算一个峰值数据，日常APP可考虑使用 峰值=4 * 日均【当然还是要看你具体的访问量】
结论
一般推荐，如果你：
没啥人用的服务 tps 20，返回有300ms就行了
十万到百万级的服务，响应能达到tps50 /200ms就可以了
后台服务，能达到tps 20 / 200ms即可（通常后台同时使用也没多少人）
秒杀类的短时间高并发……TPS100或200（小型网站） 在 100ms内响应 应该也能撑一段时间（具体情况还是要看业务量，大型网站同一时刻许多秒杀活动，小型网站可能只有一个，不考虑分布式服务情况下）