开发的原因是需要了解吞吐量(TPS )、QPS、并发计数和响应时间(RT )的一些概念。 在百度百科上查了一下，记录如下。 1 .响应时间) RT )响应时间是系统响应请求的时间。 直观上，该指标与人类对软件性能的主观感受非常一致，因为整个计算机系统都完整地记录了处理请求的时间。 通常，一个系统提供许多功能，不同的功能具有不同的处理逻辑，因此不同的功能具有不同的响应时间，即使是相同的功能，响应时间也因输入数据而异。 因此，在讨论一个系统的响应时间时，人们通常指的是该系统所有功能的平均时间或者所有功能的最大响应时间。 当然，在许多情况下，您需要考虑每个功能或每个功能组的平均响应时间和最大响应时间。 在没有独立并发操作的APP应用系统中，响应时间被认为是合理而准确的性能指标。 另外，响应时间的绝对值并不直接反映软件性能的高低，软件性能的高低实际上依赖于用户对其响应时间的接受程度。 对于一个游戏软件来说，响应时间应该小于100毫秒比较好。 响应时间在1秒左右的话可能会勉强接受，但是响应时间达到3秒的话就完全不能接受了。 在编译系统中，完整编译大型软件的源代码可能需要几十分钟以上，但这些响应时间对用户来说是可以接受的。 2 .吞吐量(Throughput )吞吐量是指系统在单位时间内处理的请求数。 在没有并发的APP应用系统中，吞吐量和响应时间成反比，实际上吞吐量是响应时间的倒数。 如前所述，在单用户系统中，响应时间(或系统响应时间和APP延迟时间)可以很好地衡量系统性能，但同时系统通常需要将吞吐量作为性能指标。 在多用户系统中，如果只有一个用户使用，则系统的平均响应时间为t。 如果有n个用户在使用，则每个用户看到的响应时间通常不是nt，而是往往远远小于nt。 当然，在特定情况下可以大于或等于nt。 这是因为处理每个请求需要大量资源，而且在处理每个请求的过程中，许多资源很难同时执行，因此在特定时刻不会消耗大量资源。 这意味着，处理单个请求时，每个时间点都可能有很多资源处于空闲状态；处理多个请求时，只要资源配置合理，人均响应时间并不会随用户数量的增加而线性增加。 实际上，随着用户数量的增加，每个系统的平均响应时间也不会有很大的变化。 这也是使用吞吐量来衡量并发系统性能的主要原因。 总的来说，吞吐量是一个比较常见的指标，如果两个具有不同用户数量和用户使用模式的系统的最大吞吐量基本一致，则可以确定两个系统的处理能力基本一致。 3 .并发用户数并发用户数是指系统可以同时托管的使用普通系统功能的用户数。 并发用户数是比吞吐量更直观，但更常见的性能指标。 实际上，同时用户数是非常不准确的指标。 因为不同的用户使用模式会在单位时间内向每个用户发出不同数量的请求。 以网站系统为例，假设用户只有注册后才能使用，但注册用户并不随时都在使用该网站，所以在特定时刻只有部分注册用户同时在线，在线用户通过web 因此，在特定时刻只有部分在线用户同时向系统发出请求。 这样，关于网站系统，有注册用户数、在线用户数、并发请求用户数三个统计。
因为注册用户可能不会长时间登录网站，所以使用注册用户数作为性能指标会产生很大的误差。 在线用户数和同事请求的用户数是性能指标。 相比之下，以在线用户为性能指标更直观，以并发请求用户数为性能指标更准确。 4. QPS (每秒查询率) Query Per Second (每秒查询率) QPS是衡量特定查询服务器在规定时间内处理的业务量的标准，在因特网上，作为域名系统的服务器的设备的性能是每秒查询率对应fetches/sec，是每秒的应答要求数，也就是最大吞吐量能力。 (它看起来类似于TPS，但只是应用于特定场景的吞吐量。)