我正在构建一个图像共享站点，并且想了解使用 PHP 动态调整图像大小并存储调整后的图像的优缺点。
哪个更快？
哪个更可靠？
这两种方法在速度和性能上的差距有多大？
请注意，无论是图像通过 PHP 脚本获取统计信息（如视图）还是允许热链接等...所以如果我选择存储调整大小的图像，它不会是图像的直接链接。
感谢您的 cmets 或任何有关该主题的有用链接。
【问题讨论】：
标签： php performance thumbnails image-resizing
这绝对是无与伦比的事情。
实际上，动态调整图像大小就像在您自己的服务器上运行 DoS 攻击一样。与向 php 脚本提供一个通常的请求相比，调整一张普通图像的大小需要更多的 CPU 和 RAM。这已经对性能产生了巨大影响。然而，通常的缩略图不是单独显示的，而是以数字显示的。因此，在只显示一个画廊页面的同时，您正在创建数十个负载繁重的进程，将服务器负载增加十倍或更多。
快速而肮脏的测试来证明我的话： 让我们尝试调整相对较小的 1.3 兆像素图像的大小
$ /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.1 秒，因此，显示 10 个图像预览会占用一整秒的 CPU 时间。虽然正确编写的 PHP 画廊页面将花费大约 0.01 秒。因此，通过动态调整大小，您将服务器负载增加了 100 倍。
与内存相同。每个调整大小进程将占用不少于 10M 的内存（调整 100k 图像文件的大小！），总和为 100M。虽然 PHP 脚本的通常内存限制仅为 8M，而且很少达到。
这是现实生活中的数字。
与此问题相关的一件有点有趣的事情：
完全是同一位 PHP 用户，他们轻松地扔掉了 1000000s 的 CPU 周期，同时却令人难以置信地嫉妒多余 1 或 2 个！这不是修辞格，这里是我所说的一个例子：
来自某人的similar question，他的非常关心同时与speed difference between Constants, Variables or Variable Arrays 一样微不足道。还有谁最近run into allowed memory size exhausted problem，好像这样的灾难还不够。
这个网站上有大量的问题和答案，讨论任何操作的纳秒速度差异，以无穷无尽的尊严回答，运行数百万次迭代的测试，以显示每个 CPU 周期的一次性操作之间的差异绝对可以忽略不计。
同时也有这样的问题 - 关于两种方法之间在性能方面的巨大、无与伦比的差异，这看起来与作者相同。
这就是普通 PHP 用户和这个网站的问题。
前者只是没有办法分辨真实的东西和微观的东西。
然而，后者没有对问题进行健全性检查的机制 - 每个人都以同样的热情回答，即使两个问题相互矛盾（并且都具有常识）。
【讨论】：
动态调整大小可能是一个代价高昂的过程（时间方面），具体取决于图像的初始大小。我已经在生产系统中完成了它，但是当我有选择的时候，我强烈倾向于缓存到磁盘。毕竟，磁盘空间很便宜，加载时间就是 Web 上的一切。即使您只是以特定大小缓存缩略图并在其他任何地方进行动态调整大小，您也可以大大减少画廊风格图像列表的加载时间。
【讨论】：
这听起来像是过早的优化。您知道您的网站将拥有多少用户/您的服务器将拥有多少计算任务？使用最简单（维护方面）的选项，即动态调整大小，直到性能成为问题，然后从那里弄清楚该怎么做。
如果它们可能会被重复命中，那么对重新缩放的图像实施某种服务器端缓存可能是一个想法，但我认为这种需要不会扩展到显式预渲染。
【讨论】：
我强烈建议您缓存图片，不要随意调整大小。
调整图像大小对您的服务器来说非常消耗 CPU 和内存。
如果您有一个动态缩放的图片库，页面加载图片的速度会很慢，比如 3-10 秒，具体取决于原始文件大小。
调整大小时，大约需要 3 个字节 pr 像素的内存。所以如果你有一个 1000x1000 的图像要调整大小，大约需要 3MB 的内存。如果您的一个网页有许多这样的动态调整大小的图像，比如 20 个，则它将占用您服务器的大约 60MB 内存。 也许不是，因为大多数客户端当时只请求 4 张图片，但 12MB 对于页面加载来说仍然很多。如果源图像小于 100x100 像素，我只会动态缩放。
提示：用于缩放和保存拇指的出色库是 PhpThumb
【讨论】：