保持连接开放显然会消耗资源，即使它们只是等待响应的 TCP 连接。
显而易见的是，与进行数据库查询并转换结果以创建响应的过程相比，它们消耗的能量并不那么多。
我的问题是，当我计算提高超时值的潜在资源消耗时，我考虑到的似乎产生了乐观的结果，我想知道我是否遗漏了什么。
我通过思考来探索这一点，假设操作将成功结束，并且无论哪种方式都会得到相同的结果。想象一下，我们要么提高超时值，要么奇迹般地让外部服务器响应更快。这样我们就可以隔离保持连接更长时间的影响。然后我可以将它们与未完成过程的影响分别进行比较。
我考虑的事情是：
- 内存消耗：我发现这是最令人担忧的。但是，当打开的连接几乎花费所有时间等待有效负载时，它已分配了其生命周期的最小内存量。
- CPU使用率：接近于零。该过程本身只是检查响应是否已经存在。操作系统应该保持连接，但想不出任何重要的计算
- 并发打开的连接数：一项简单的研究表明，上限约为 30 万。如果我的数字远远达不到这个数字，我们就没事了
- 插座数量：同样，如果我的系统还远未达到极限，那就没问题
- 端口数：相同：我们知道极限，我们知道是否正在突破它。
- 最大打开文件数：我们可以测试每个过程需要多少并进行相应的计算
- 让其他服务保持繁忙：我们可能会保持数据库连接繁忙，入站连接等待我们的进程等等。
这就是我能想到的所有缺点。就我而言，除了内存之外，其他所有项目都不值得计算，而且内存消耗也不会受到太大影响。
当我将此与无法完成操作进行比较时，天平进一步倾向于增加超时。在我们的特定情况下，如果操作失败，下一个请求将需要更长的时间来尝试补偿，这包括高超时的所有缺点。增加超时后，等待的总时间会更少。
这件事引起了我和老板的轻微争论，他似乎认为这个问题（或者我）不值得争论。那次谈话没有得到任何建设性的结果，所以我来到这里。
我是否遗漏了任何值得注意的方面？我的任何物品是否被低估了？