我正在测试一个应用程序(后端，它几乎没有暴露的API)。满足 TPS，满足响应时间。但是，当我增加线程(以 Jmeter 为单位)时，测试失败，开始出现错误。(我正在以并发用户身份阅读线程)所以，我们现在有人说我的申请是瓶颈。前端应用程序的要求是 1000 个并发用户。前端应用程序中 1 笔交易的用户旅程约为 2 到 3 分钟。但是，我正在测试的应用程序是无状态的应用程序(后端)，它在毫秒内响应，并且所需的 TPS 本身满足 50 个线程。但是我被要求为我的应用程序测试 1000 个线程，并且前端应用程序具有该要求。他们这么说是对的吗？是否可以将前端应用程序 1000 个并发用户的要求也应用于后端应用程序。
前端是后端的Web表示，不是吗？所以没有后端，前端就无法工作。
通常，提供业务非功能性需求的产品所有者根本不关心底层实现(前端、后端、数据库、负载均衡器等)，因此 1000 个并发用户的要求适用于整个集成系统。
现在，您的目标是确定瓶颈，通常该过程如下所示：
- 在受测应用程序(CPU、RAM、交换、网络、磁盘等)上设置基线性能计数器的监视。你可以为此使用JMeter PerfMon插件。
- 从 1 个虚拟用户开始测试并逐渐增加负载，除非响应时间超过可接受的阈值或开始发生错误(无论第一次出现什么)
- 检查资源(CPU、RAM 等)是否可能是原因。如果是 - 您只需要迁移到更强大的服务器或扩展应用程序或对其进行优化。如果否 - 请检查您的应用程序基础结构(Web 服务器、数据库服务器等的设置)，因为它可能不适合更高的负载。
- 也可能是应用程序代码本身是瓶颈。在这种情况下，使用分析工具来识别最慢的函数、最大的对象、最长的数据库查询等。
如果你有一个没有NIO的微不足道的雄猫，前端知道你不支持足够的并发用户的唯一方法是serversocket TCP同步队列太短。(客户端获取 TCP RST)
码头和雄猫都有设置使服务器套接字队列更长。这是让任何人以某种方式检测到并发请求限制的最简单方法。
例如，您只能"服务"30 个线程和连接，但在服务器套接字接受队列中仍有 1000 个 TCP SYN 挂起。这意味着连接是排队的，因此被接受，并且只要客户端可以判断，并发。他们只是碰巧有一个可疑的更长的 E2E 时间，因为这个队列在被送达之前有延迟。
无论后端是什么，在某些时候，这 1000 个请求都不会并发：也许它们在 cassandra 连接中汇集到 4 个线程中，或者在可怜的 bean 验证缓存前面的某个大锁中汇集到 1 个线程中，等等......
通过排队，您可以保留对并发的控制，以保持性能的最佳点，并且任何多余的请求都会逐渐转换为更多的 E2E 时间来遍历队列并获得服务。
所以，是的，他们可以要求你能够接受 1000 个请求，但他们不知道时间是如何分解的。