我们有一大堆分布式客户端，它们除其他外，还将日志文件上传到我们的 Apache 服务器。
我们搞乱了一些日志的日志轮换，因此我们现在每天多次从这些客户端上传相对较大的文件。显然，解决办法是让日志轮换正常工作，并让客户端更加智能，这样它们就不会再这样做了。将任何更改推送到客户端需要几天时间，甚至可能是一两周的时间。
与此同时，我们的 3 个 T1 已经 100% 承担了这些上传任务，许多重要的连接（比日志上传重要得多）都超时了。
日志上传由在 mod-wsgi 下运行的 Python 脚本处理，我们尝试让它（通过 Python 脚本）立即发送 200 成功。这不起作用 - curl（我们用于上传的工具）将在 30 秒后报告 200 和管道损坏，但在这 30 秒内它仍在上传。
对此我们有什么建议吗？我们其实不太在意是否丢失了日志文件，但我们确实希望重要的流量能够通过。
答案1
是否可以将您的 DNS 更改为指向可以处理负载的服务器（或负载平衡的服务器场）和/或具有更好的网络连接的服务器，这样您就不会在 3 T-1 上遇到瓶颈？
如果客户端连接到的是 IP 地址而不是 DNS 名称，您是否与上游提供商讨论过更改路由，以便将有问题的 IP 地址路由到提供商现场或附近的托管设施的服务器空间？
答案2
为什么不尝试不使用 apache 的另一种方法，比如 iptables。如果它适合您的需要。
这是一个很好的开始。
刀具：
http://www.lowth.com/cutter/
Apache 或客户端不会立即停止。因为连接已经建立。即使您重新启动 Apache。或阻止端口 80 用于上传位置。它也会等到超时结束。
但是使用 cutter，您可以在某一特定时间终止连接。这将在您需要的时间内为您提供足够的带宽/资源。缩短您的连接。apache 配置中的超时以节省内存和死/僵尸 apache 子进程。然后使用 cutter 来杀死不必要的上传。
答案3
发送 HTTP 响应很好，但您真正需要做的是关闭连接。我不太了解 mod_wsgi，但在 mod_php 中，例如，一个简单的：
exit(0);
脚本顶部的 运行起来非常顺畅。在脚本被调用之前，您仍然（可能）会读取输入缓冲区的字节数，但这通常不是问题。
由于您使用的是 Apache，因此另一种选择是在更高级别阻止事物；向更新的客户端添加新的 GET 字符串，然后添加如下配置：
RewriteEngine on
RewriteCond %{QUERY_STRING} !.*isNotBraindead=1.*
RewriteRule path/to/python/script.py - [F,L]
答案4
在Apache配置中临时添加：
<Location /some/url/to/upload/handler>
Deny from all
</Location>
基本上，禁止访问用于上传处理程序的 URL。
这假定上传处理程序的完整 URL 路径不用于其他任何用途。
因为返回了错误（即非 200 状态），Apache 将立即断开连接。