问支持本地http服务器上的保持活动套接字的问题

EN

我目前正在尝试构建一个http服务器。服务器由一个侦听线程使用select(.)进行多线程。以及由线程池管理的四个工作线程。我目前正在管理每秒14k-16k的请求，文档长度为70字节，响应时间为6-10 I3，在核心I3 330米上。但这是没有保持活力和任何我服务的插座，我立即关闭，当工作完成。

编辑：当检测到套接字上的活动时，工作线程处理已分派的“作业”，即。服务请求。在“作业”完成后，如果没有更多的“作业”，我们就睡觉，直到更多的“作业”被分派出去，或者如果已经有可用的作业，我们就开始处理其中的一个作业。

我的问题始于我开始尝试实施维持生命的支持。在激活“保持活动”的情况下，我只管理每秒1.5k-2.2k请求和100个打开的套接字。这个数字增长到12k左右，有1000个打开的插座。在这两种情况下，响应时间大约在60-90ms左右。我觉得这很奇怪，因为我目前的假设是，请求应该上升，而不是下降，响应时间应该有希望下降，但绝对不会上升。

我尝试了几种不同的策略来解决低性能的问题：

1. 调用选择(.)/pselect(.)使用一个超时值，以便我们可以重新构建FD_SET结构，并侦听阻塞后到达的任何附加套接字，并为任何检测到的套接字活动提供服务。(除了性能低下之外，还存在在阻塞时关闭套接字的问题，从而导致select(.)/pselect(.)2.让一个只接受新连接的侦听线程和一个保持活动的线程通过管道通知在我们阻止和任何新套接字活动之后到达的任何新套接字，并重新构建FD_SET。(这里的附加问题与‘1.’中的问题相同).3。选择(.)/pselect(…)在超时的情况下，在完成新工作时，分离具有活动的套接字的链接列表条目，并在请求被服务后将其添加回。希望重建FD_SET的速度会更快。这样，我们还可以避免尝试侦听任何坏的文件描述符。合并(2.)和(3.)

​

-。可能还有几个，但他们逃出了我的自动取款机。

“保持活动”套接字存储在一个简单的链接列表中，该列表的add/remove方法被一个pthread_mutex锁包围，负责重建FD_SET的函数也有这个锁。

我怀疑主要的罪魁祸首是互斥锁/解锁，我试着分析这个问题，但无论是gprof还是google，无论是引入极端不稳定，还是明显拒绝收集任何数据(这可能是我不知道如何正确使用这些工具)。但是，删除锁可能会使链接列表处于非正常状态，并可能崩溃或将程序置于无限循环中。我还怀疑select(…)/pselect(.)当我使用它时，我很有信心这不是问题，因为即使没有它，性能也很低。

我不知道该如何处理“保持生存”套接字，我想知道你们是否对如何解决低性能的问题有任何建议，或者对我可以用来支持“保持生存”套接字的任何替代方法提出建议。

• 如果您需要更多的信息才能正确地回答我的问题，请不要犹豫，我将尽力向您提供必要的信息，并用这些新的信息更新问题。