如何跟踪与cfcontent服务文件绑定的请求数量？

Question

由于APE的mod_xsendfile不能与CF9的jrun_iis6_wildcard.dll一起使用,因此我可以安全地使用服务文件<cfcontent>.现在的问题是,如果文件下载很大,或者连接速度很慢,它会在很长一段时间内占用CF请求.如果没有办法强制实施硬限制,理论上可以将所有请求与服务文件捆绑在一起.

我尝试在下面做额外的日志/逻辑,<cfcontent file="">但我注意到它们永远不会被触及并执行.

<cfcontent file="test.mp3">

<!--- won't reach here --->
<cfdump output="console" var="#now()# download done!">

通过处理太多的cfcontent请求,可以做些什么来避免CF被降级？

更新:好消息!CF10适用于APE的mod_xsendfile!

Answer 1

解决方案1

考虑到由于不可控因素（线程“卡住”、服务/服务器关闭等），您不太可能获得 100% 真实的记账，您可以执行以下操作：

如果您只想跟踪总请求数，则可以使用在开始提供文件时递增的应用程序变量。然后，当内容完成时，您将减少计数。但是，您需要小心使用 cflock 以确保此更新不会导致任何问题。

如果您想将其记录到文件中，您可以执行相同的操作，但仍将其包装在 cflock 中，以确保同时读取/写入文件的请求不会遇到任何问题。

如果您使用 SQL，您可以创建一个表来表示文件，并为每次获取添加一条记录和适当的信息

• 文件名
• 完成为位是/否字段，默认为 false
• 用户/客户信息
• 开始日期/时间默认为现在，
• 结束日期/时间默认为空，
• 状态“正在下载”
• 任何其他信息

使用返回的标识 cfcontent 文件，然后在完成后使用指定的 ID、正确的日期/时间和状态“成功”对表进行更新，并完成为“是”。

在 onerror 期间，您可以更新表以反映状态“错误 [相关错误详细信息]”并已完成为 1。添加一个包罗万象的更新以更改为已完成 = 1 或清除未完成的记录并不是一个坏主意。可用（可能在启动时或一段时间后的应用程序期间）

这将允许您查询此表以获取当前待处理请求的总数（以及它们是什么等）

但是，这仅解决了长时间运行的请求的问题。

解决方案2

理想情况下，问题是安全地返回文件内容。根据文件的敏感程度（例如，首选私有文件，但如果不是，则不是世界末日），您可以将它们“复制”到适当的 Web 可访问目录，但使用 UUID 作为名称。假设它是 Secret1.pdf，您将使用 cfdirectory 创建一个目录，然后将文件复制到其中。给你这样的东西：

/files/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxx/Secret1.pdf 然后执行 a 重定向到该目录。

然后，您可以设置计划任务或网关或您喜欢的任何方法来清除早于设定小时数的目录。例如，从现在起 30 分钟后删除目录 xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxxxxx 及其所有文件。