测试应用程序的压力和数据库连接失败
我目前有一个nodejs(nestjs)应用程序和postgres数据库。数据库的最大连接数为1700，我正试图在一个每秒的一个实例中触发1000个请求。在程序/数据库资源消耗不大(CPU/内存)的情况下，测试大约需要400万才能完成，并且我不断地分析数据库，连接池一点也没有耗尽，即使这样，我也会预期会出现不同的错误(例如，已经有太多的客户端)。我遇到的错误是这样的：
2023-01-31T08:46:17.025832753Z at TCPConnectWrap.callbackTrampoline (node:internal/async_hooks:130:17)
2023-01-31T08:46:17.027421325Z [31m[Nest] 52 - [39m01/31/2023, 8:46:17 AM [31m ERROR[39m [38;5;3m[ExceptionsHandler] [39m[31mconnect ETIMEDOUT 20.111.121.122:5432[39m
2023-01-31T08:46:17.027480928Z Error: connect ETIMEDOUT 20.111.121.122:5432
2023-01-31T08:46:17.027490729Z at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1278:16)
2023-01-31T08:46:17.027495029Z at TCPConnectWrap.callbackTrampoline (node:internal/async_hooks:130:17)
2023-01-31T08:46:17.029191106Z [31m[Nest] 52 - [39m01/31/2023, 8:46:17 AM [31m ERROR[39m [38;5;3m[ExceptionsHandler] [39m[31mconnect ETIMEDOUT 20.111.121.122:5432[39m
2023-01-31T08:46:17.029645727Z Error: connect ETIMEDOUT 20.111.121.122:5432
2023-01-31T08:46:17.029700829Z at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1278:16) 由于20.111.121.122:5432中属于postgres的端口号，到目前为止，我唯一能从这个日志中破译的事情是，这个应用程序无法与数据库建立连接。
目前，我会说，20%-30%的失败是因为这，在一个1000请求高峰。在正常负荷下，这种情况通常不会发生。
所以，我的问题是，如果一个应用程序或数据库放弃这样的连接是正常的，即使资源是可用的？或者这应该是程序员方面的一个更大的问题吗？我是不是误解了上面的日志？还是有可能解决这个问题？请给我一些有关这方面的见解，特别是关于postgres数据库。
编辑：
This is how I cache the connection for each db:
cache = {};
schemas = ['sche1', 'sche2', 'sche3',......, 'sch4']
db = ['db1', 'db2', 'db3', 'db4']
for(let i=0; i< schemas.length; i++){
baseConnection = {
host: '23',
db: selectAppropriateDb(schemas[i]);
port: 5432,
user: selectUser(schemas[i])
poolSize: 20
password:
}
const dataSource = new DataSource(baseConnection);
cache[schemas[i]]= await dataSource.initialize();
}在k6中，我只创建了1000个虚拟用户，并发送了如下请求：
http.get('testroute', getTokenForIthSchema(uniqueId))回答 1
Software Engineering用户
发布于 2023-02-05 05:39:22
poolSize: 20在k6中，我只创建了1000个虚拟用户
你提到了我还不熟悉的"k6“。
我想我听到您说过，您不是在单个客户端主机上使用(多线程)单个进程，而是要求k6使用大量服务器发送所提供的负载。
K6生成1000个虚拟用户，每个虚拟用户最多可以创建20个到postgres服务器的TCP连接的池限制。
换句话说，如果您的虚拟用户正在循环处理大量请求，则您的虚拟用户可以同时保持对端口5432的20,000个TCP连接的打开。攻击一个有8个核心的服务器。
流量控制(“背压”)将是这里的一个问题。您的PG服务器只能做这么多。当它得到一个提供负载的狄拉克脉冲时，它的响应速度不会无限快。
Postgres是一个守护进程，在用户空间中运行。它在5432发出了一个约束(2)调用，并随后发出了一个听(2)。本质上，它告诉内核它对5432到达的电话感兴趣，并且内核同意转发这样的呼叫。有一个极其重要的参数：
int listen(int sockfd, int backlog);通常情况下，backlog小于30。我注意到30比1000还少。(编辑:事实证明，一些守护进程的缺省值接近于100，甚至更多，但远远低于1000。)
backlog参数定义了sockfd的挂起连接队列可能增长到的最大长度。如果连接请求在队列已满时到达，则客户端可能收到错误.
您可以使用$ netstat -an、$ ss -it; ss -lt或# lsof监视内核的TCP 电路板协议控制块。关键是，对于零客户端错误，postgres (或任何守护进程)需要注意到传入的电话，并在超过待办事项之前使用接受(2)接听电话。一旦队列满了，新的电话就会掉在地板上。这最终(在客户端超时之后)会产生类似于日志中所看到的消息。
让QPS是每秒的查询，其中一个查询是非常简单的“从some_table选择最大(Id)”；
下面是关于您的DB服务器的一些基本事实，您确实应该知道：
- 使用一个持久的TCP连接，一个客户端主机有多少个QPS和一个时间正确.循环实现？这是闭环。
- 随着线程(或进程)数量的增加，同一个客户端实现了多少个QPS？它会使DB服务器饱和吗？
- 现在增加客户端主机的数量。什么时间循环，跨越多少个客户端，将使服务器饱和？总共有多少QPS？
- 现在切换到更困难的问题:创建连接，执行简单的查询，关闭连接。这是开环，其中
backlog变得相关。一个客户端实现了多少个QPS？ - 使用(3.)中找到的客户端主机数量，这些客户端实现了多少个QPS？
运行实验(1.)一点都不容易。
当你到达(5.)您希望将客户端建模为泊松到达，因为这具有“无记忆”的可取特性。来访者对彼此一无所知。它们是用一个参数lambda建模的，它允许您讨论个人或整个人口在一秒或一个月内的预期到达人数。
将负载增加到给定的服务器，使其饱和，并注意lambda的值。现在使用2倍或10倍的值。这是一个肯定的事情，服务器将无法跟上，您将看到错误。
Web服务器，比如搜索结果的初始页面的google，是开环的--如果它们减慢响应速度，就不会在短期内降低访问者的到达率。数据库服务器通常是闭环的--我们假设客户端主机(如web服务器)维护长期的TCP连接，并且减慢选择响应将减慢SQL查询的提供速率。
了解了所有这些对于您的特定设置，您将能够很好地确定您的DB服务器可以为您的各种web服务器提供多少同时(且寿命很长) TCP连接。如果你超过这个水平，坏的事情就会发生。如果web服务器不断地拆除短命的连接并重新创建新的TCP连接，那么糟糕的事情就会发生。
此外，您还想了解实际工作负载中的实际查询是如何与上面非常简单的查询执行不同的。
向单个主机同时发送1000个连接请求不是通信协议。这不是一个基准。正如您共享的日志中所反映的那样，这是灾难的根源。
想必您希望测量吞吐量，即每秒感兴趣的应用程序级事件的数量。失败的连接尝试并没有增加业务的底线，它是没有用的。您希望通过e2e系统来度量实际使其通过的事件。所以，从小的地方开始，有10个虚拟用户，然后拨起来，直到你几乎没把东西弄坏。现在您可以知道服务器容量是什么了。这比知道“容量小于1000个开环用户”更有用。莱纳德克莱因洛克的“排队系统”指出，一个闭环的客户端服务器系统永远不会被淹没，它只会让客户等待更长时间的答案。开环闪光灯击中网站或PG服务器可以轻易压倒backlog和其他限制，导致用户可见的错误，而不是用户可见的延迟。
标杆很难。决定你的基准目标。写下来。处决他们。
https://softwareengineering.stackexchange.com/questions/443782
复制相似问题
腾讯云开发者
