客户端/服务器应用程序 – 我们遇到logging无法上传的问题。 看起来，我在通信插件中使用的方法是尝试打开太多的连接（每个Action要上载一个），并且在大约300次连接尝试后网关拒绝它们。 在我的testing过程中，问题只发生在大约300次连接尝试之后。 但是，我相信上限是基于Apache使用的全部连接。 我认为Apache只允许总共500个连接。 当有更多的行动上传比从Apache有可用的连接，然后我们的问题出现。
需要咨询/build议/解决scheme等….. Linux服务器瓦特/ 8GB
一个build议，我们看wa执行涉及cachinglogging上传到每个客户端计算机上的特殊文件夹（[APP_DATA] / SCI / CACHED_UPLOADS）一旦cachinglogging将保留在文件夹，直到成功上传到服务器。 它将被从文件夹中删除。 也会有一个“企图”的反击。 如果经过一定次数的logging仍然无法上传，它将被移动到“失败”文件夹。 我们稍后可以修改我们的应用程序来查看此文件夹的报告目的。 此方法将使用单个连接上载所有caching的文件。
我不喜欢这个解决scheme，因为我们需要将脚本推送到数以千计的客户端计算机上。 我宁愿在Linux服务器上有解决scheme。
不幸的是，你没有提供足够的细节来给出一个很好的答案。 你只是POSTing数据到一个Web应用程序/服务？ 是否有你需要运行Apache的原因？ 什么是在客户端运行这个“插件”？ 它发送什么样的数据？ 什么是“logging”，等等
无论如何，我现在可以告诉你，你的应用可能需要重构。 您需要在应用程序前部署某种持久队列，以便可以吸收客户端计算机发出的请求，并以可处理的速度将其发送到您的应用程序中。 互联网上有很多这样的阅读材料，但是如果你不熟悉并且需要一个开始的地方，那么zeromq的文档是相当方便的（ http://www.zeromq.org/intro:read-the-manual ）
如果重构不是一个选项，您可能需要将一堆服务器粘贴到负载均衡器后面来分析问题。
在即时期间，虽然..看看你的平均apache进程的足迹，并获得尽可能多的subprocess，适应内存。 然后找出你的平均请求需要多长时间，并降低你的KeepAlive时间。 如果你运行的是默认值，那么客户端机器的每个连接将占用一个subprocess120秒左右。 切换到像nginx这样的东西也是一种select。 它比Apache更好的线程，但我只有经验使用它来加速静态内容交付; 在这个用例中我没有尝试过。 其他人可能在这里有更多的信息。