客户端/服务器应用程序——我们遇到了记录上传失败的问题。看来我在通信插件中使用的方法是尝试打开太多连接（每个要上传的操作一个连接），网关在大约 300 次连接尝试后拒绝它们。在我的测试过程中，问题仅在大约 300 次连接尝试后发生。但是，我认为上限是基于 Apache 使用的总连接数。我认为 Apache 只允许总共 500 个连接。当要上传的操作多于 Apache 可用的连接数时，就会出现问题。
需要建议/解决方案等...... 配备 8GB 的 Linux 服务器
我们考虑实施的一个建议是将要上传的记录缓存到每台客户端计算机上的一个特殊文件夹 ([APP_DATA]/SCI/CACHED_UPLOADS )。缓存后，记录将保留在文件夹中，直到成功上传到服务器。然后它将从文件夹中删除。还会有一个“尝试”计数器。如果在尝试一定次数后仍无法上传记录，它将被移动到“失败”文件夹。我们稍后可以修改我们的应用程序以查看此文件夹以进行报告。此方法将使用单个连接上传所有缓存文件。
我不喜欢这个解决方案，因为我们需要将脚本推送到数千台客户端计算机。我更喜欢在 Linux 服务器上使用解决方案。
答案1
不幸的是，您没有提供足够的细节来做出良好的回应。您只是将数据发布到 Web 应用/服务吗？您有什么理由需要运行 apache？客户端上运行的这个“插件”是什么？它发送什么类型的数据？“记录”到底是什么，等等。
无论如何，我现在可以告诉你，你的应用程序可能需要重构。你需要在应用程序前面有某种持久队列，这样你就可以吸收来自客户端机器的请求，并以应用程序可以处理的速率将它们输入到应用程序中。互联网上有很多关于这类内容的阅读材料，但如果你不熟悉并且需要一个起点，zeromq 的文档相当容易理解（http://www.zeromq.org/intro:read-the-manual）
如果重构不是一种选择，您可能需要通过将一堆服务器放在负载均衡器后面来对问题进行分类。
不过，就目前而言，看看您的平均 Apache 进程的占用空间，并启动尽可能多的子进程，只要内存可以容纳。然后计算出您的平均请求需要多长时间，并降低您的 KeepAlive 时间。如果您以默认值运行，那么来自客户端计算机的每个连接都将占用一个子进程 120 秒左右。切换到 nginx 之类的东西可能也是一种选择；它比 Apache 线程更好，但我只使用它来加速静态内容交付；我还没有在这个用例中尝试过它。其他人可能有更多信息。