我正在构建一个图像共享网站，并希望了解使用PHP动态调整图像大小并保存已调整大小的图像的优缺点。
哪个更快？
哪个更可靠？
这两种方法在速度和性能方面的差距有多大？
请注意，无论哪种方式，图片都会通过PHP脚本进行视图等统计信息处理，或者如果允许热链接等等...如果我选择存储调整大小图像，则不会像图像的直接链接那样。< / p>
我将非常感谢您对此主题的评论或任何有用的链接。
答案 0 :(得分：29)
这绝对是无与伦比的事情。
实际上，动态调整图像大小就像在您自己的服务器上运行DoS攻击一样。调整一个通常图像的大小需要比向php脚本提供一个常规请求更多的CPU和RAM。这对性能影响巨大。然而，通常的缩略图不是单独显示，而是数字显示。因此，虽然只显示一个图库页面，但您正在创建数十个重载过程，从而将服务器负载增加十倍或更多。
快速而肮脏的测试证明我的话： 让我们尝试调整相对较小的1,300万像素图像
$ /usr/bin/time --format="%MK mem %Es CPU time" /usr/bin/convert angry_birds_1280x800.jpg -resize 100x100 thumb.jpg
10324K mem 0:00.10s CPU time
它花了我们0,1s，所以，显示10个图像预览将占用你的CPU时间的整整一秒。虽然正确编写PHP画廊页面将需要大约0,01s。因此，通过动态调整大小，您将服务器负载增加了100倍。
与记忆相同。每个调整大小的过程将使用不少于10M的内存（调整100k图像文件的大小！），总和为100M。虽然PHP脚本的通常内存限制仅为8M，但很少达到。
这是现实生活中的数字。
与此问题有关的一件有趣的事情：
完全相同的PHP用户，他们很容易丢掉100万个CPU周期同时令人难以置信地嫉妒1或2个！这不是一种比喻，这里是我所谈论的一个例子：
来自某人的similar question，其非常关注同时与speed difference between Constants, Variables or Variable Arrays一样微不足道。谁最近run into allowed memory size exhausted problem，好像这样的灾难还不够。
在这个网站上有很多问题和答案，讨论任何操作的纳秒速度差异，以无穷无尽的尊严回答，运行数百万次迭代的测试，以显示每个CPU周期的一次性操作之间的差别可以忽略不计。
与此同时存在这样的问题 - 关于两种方法之间在性能方面存在巨大的，无可比拟的差异，这两种方法看起来仅仅与作者相同。
这是普通PHP用户和本网站的问题 前者没有措施从微观事物中分辨出真实的东西 然而，后者没有对问题进行健全性检查的机制 - 每个人都以同样的热情回答，即使两个问题相互矛盾（并且都有常识）。
答案 1 :(得分：22)
动态调整大小可能是一个代价高昂的过程（按时间），具体取决于图像的初始大小。我已经在生产系统中完成了它，但是当我有选择时，我强烈支持缓存到磁盘。毕竟，磁盘空间很便宜，加载时间就是Web上的一切。即使您只是以特定大小缓存缩略图并在其他地方进行动态调整大小，也可以大大减少图库样式图像列表的加载时间。
答案 2 :(得分：16)
这听起来像是过早优化。您知道您的网站将拥有多少用户/您的服务器将拥有多少计算量？选择最简单的（维护方式）选项，即动态调整大小，直到性能成为一个问题，然后从那里找出该做什么。
对于重新调整后的图像，如果它们可能被重复命中，可能会实现某种服务器端缓存，但我认为这不需要扩展到显式预渲染。
答案 3 :(得分：15)
我强烈建议您缓存图像，而不是即时调整大小。
调整图像大小对于服务器来说非常占用大量CPU资源并且占用大量内存。
如果你有一个可以随时扩展的图像库，页面会慢慢加载图像，比如3-10秒，取决于原始文件大小。
调整大小时，内存占用大约3个字节。因此，如果要调整大小为1000x1000的图像，则需要大约3MB的内存。如果您的某个网页上有许多这些大小调整运行的图像，比如20，那么服务器的RAM大约需要60MB。 也许不是，因为大多数客户当时只请求4个图像，但是12MB对于页面加载仍然很多。如果源图像小于100x100像素，我只会动态缩放。
提示：用于缩放和保存拇指的优秀库是PhpThumb