我有一个我正在创建的服务器（一个消息服务），我正在做一些初步测试来对它进行基准测试。到目前为止，处理数据的最快方法是直接在用户进程上执行并使用工作池。我测试了产卵，这是令人难以置信的缓慢。
测试只是连接10k用户，每个用户同时发送15kb数据（或尝试至少）并让服务器处理数据（总长度，标题和有效负载）。
当您有足够的工作人员来抵消连接数量时，我对工作池的问题是唯一的问题。例如，如果您有500k或100万用户，则需要更多工作人员来处理所有并发数据。而且，对于我的测试，拥有1000名工作人员会使其无法使用。
所以我的问题如下：什么时候使用工人池是有道理的？是否会有一个临界点，我必须使用工作人员来处理数据以释放用户进程？有多少工人太多，是500,000太多了？
而且，如果工作人员是可行的（对于那些大规模的并发分布式服务器），我猜您可以根据需要动态创建/删除？
任何文献也表示赞赏！
感谢您的回答！
答案 0 :(得分：3)
也许工作池不是解决问题的最佳工具。如果我是你，我会尝试使用Jay Nelson的epocxy，它为您提供了一个非常基本的背压机制，同时仍然允许您并行化您的任务。从该库我将检查并发数量或并发控制工具。