【发布时间】：2009-11-17 23:34:45
【问题描述】：
我想增加服务器上的 max_post_size 和 upload_max_filesize，以便我的应用程序可以处理更大的文件（大至 2gb）。但在我这样做之前，有什么注意事项？显然，PHP 开发人员将大小设置为低是有原因的。我需要一定数量的 RAM 来进行操作吗？任何见解都会有所帮助。
【问题讨论】：
【发布时间】：2009-11-17 23:34:45
【问题描述】：
我看到的最大问题之一是 POSTS 是一次性交易。我的意思是，如果您的客户端正在上传一个非常大的文件，并且在完成 90% 时发生网络中断，他们将不得不从头开始。
我相信有基于 Flash 和 Java 的解决方案可以将文件分块上传并在您的服务器上重建。我只使用了一个为 Amazon 的 S3 服务（称为 Jets3t）制作的，但希望其他人可以推荐另一个。
【讨论】：
发布的数据在发布时会流式传输到内存中。将最大帖子大小乘以您希望在任何时候发布的最大用户数，这就是您需要在所有会话/进程中保存发布数据的内存量。
您的上传最大大小必须小于最大帖子大小。最大帖子大小和上传文件大小的区别在于可用于注释或消息内容等内容的数据量。
但实际上，使用户能够发布高达 2gb 的内容会导致容易的 DOS 攻击。即使您将应用程序的可用性限制在本地 Intranet 上的企业用户中，心怀不满的员工也不难让您头疼。
当然，您可以在 64 位平台上的盒子中放入大量 RAM，但我想这取决于您要花多少钱。
【讨论】：
这更多的是一个安全问题，让我们想象一下，一群黑客决定攻击您的网站并开始从多台机器上传 1.99 giga 文件。
您的服务器磁盘很快就会被填满，并且服务器会非常缓慢地变得无法使用。
对于 Nathan 提到的内存问题，我认为这是一个神话，PHP 确实在内存中存储了一些，但同时也将其放在磁盘上，因此内存量应该差不多.
您可能希望为您的用户提供某种 FTP 访问权限，以便在您的应用程序中他们能够浏览该 ftp 目录并导入任何选定的文件。 FTP 允许在连接中断的情况下追加和轻松恢复。
还必须注意在浏览器上上传 2 gb 文件的用户体验非常糟糕，就像您的浏览器会在几分钟内冻结并且您不知道它是否会卡住进度，所以使用一些 Flash/Applet基于解决方案或 FTP 的用户有一些反馈真的更好。
【讨论】：