处理这个问题的最佳方法是什么:通过PHP进行大量下载+从客户端进行慢速连接=在文件完全下载之前脚本超时

我的客户想要一种向用户提供下载的方式,但只有在他们填写注册表(基本上是姓名和电子邮件)之后。向用户发送一封电子邮件,其中包含可下载内容的链接。这些链接包含一个包、文件和用户特有的注册哈希,它们实际上会转到一个PHP页面,该页面记录每次下载,并通过将文件写入stdout(以及相应的头)将文件推出。这个解决方案有固有的缺陷,但这正是他们想要做的。需要指出的是,我极力要求他们1.)限制可下载文件的大小,2.)考虑使用CDN(他们有国际客户,但在美国托管在2台镜像服务器和使用粘性IP的负载平衡器上)。无论如何,它“适合我”,但他们的一些国际客户的连接速度非常慢(d/l速率约为60kB/秒),其中一些文件相当大(150MB)。因为这是一个为这些文件提供服务的PHP脚本,所以它受脚本超时设置的约束。一开始我把这个设置为300秒(5分钟),但是对于一些beta用户来说,这个时间不够。因此,我尝试根据文件大小除以100kb/秒的连接来计算脚本超时,但其中一些用户甚至比这个速度还要慢。

现在客户机只想增加超时值。我不想一起删除超时,以防脚本以某种方式进入无限循环。我也不想继续推超时任意一些一网打尽最低的公共分母连接率(大多数人下载速度远远超过100kb/秒)。我还想在某个时候告诉客户“看,这些文件太大了,不能用这种方式处理。你正在影响网站其余部分的性能与这些40多分钟的连接。我们要么需要重新考虑它们的交付方式,要么使用更小的文件。”

我有几个解决方案,如下:

1. 绕过脚本,直接从CDN下载URL(可以通过观察HTTP头来收集URL)。这还不错,但并不理想。
2. 展开服务器场 -将服务器场从2个服务器扩展到4个以上的服务器,并从负载平衡器中删除粘性IP规则。缺点:这些都是Windows服务器,所以它们很昂贵。没有理由说它们不能成为Linux机器,但是设置所有新机器可能需要比客户机所允许的更多的时间。
3. 安装2个新服务器,严格为这些下载服务
4. -我想到了一种检测用户当前速度的方法,在下载登录页上使用AJAX来计算下载一个已知文件大小的静态文件所需的时间,然后将该信息发送到服务器并根据该信息计算超时时间。这并不理想,但总比估计连接速度过高或过低要好。我不知道如何将速度信息返回到服务器,因为我们目前使用的是从服务器发送的重定向头。

可能性是#的1-3将被拒绝或至少推掉。那么4是一个很好的方法,还是有什么我没有考虑的呢?

(请随意挑战原始解决方案。)