我正在构建一个图像共享站点，并想知道使用 PHP 动态调整图像大小并存储调整后的图像的优缺点。
哪个更快？
哪个更可靠？
两种方法在速度和性能上的差距有多大？
请注意，无论哪种方式，图像都通过 PHP 脚本进行统计，例如视图，或者是否允许热链接等......所以如果我选择存储调整大小的图像，它不会是图像的直接链接。
我会感谢您的评论或有关该主题的任何有用链接。
问问题
16858 次
4 回答
31
这是绝对无法比拟的事情。
实际上，动态调整图像大小就像在您自己的服务器上运行 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 用户，他轻松地扔掉了 1000000 个 CPU 周期，同时却难以置信地嫉妒多余 1 或 2 个！这不是一个比喻，这是我正在谈论的一个例子：来自某人的
一个类似问题，他同时非常关心常量、变量或变量数组之间的速度差异可以忽略不计。还有谁最近遇到了允许内存大小耗尽的问题，好像这样的灾难还不够。
这个网站上有大量的问题和答案，讨论任何操作的纳秒速度差异，以无穷无尽的尊严回答，运行数百万次迭代的测试，以显示每个 CPU 周期的一次性操作之间的差异绝对可以忽略不计。
同时也有这样的问题——关于两种方法在性能方面的巨大、无与伦比的差异，这看起来与作者相同。
这就是普通 PHP 用户和这个网站的问题。
前者只是没有办法分辨真实的事物和微观的事物。
然而，后者没有对问题进行健全性检查的机制——每个人都以同样的热情回答，即使两个问题相互矛盾（并且都具有常识）。
于 2012-02-27T15:56:53.387 回答
23
根据图像的初始大小，动态调整大小可能是一个昂贵的过程（时间方面）。我已经在生产系统中完成了它，但是当我有选择的时候，我强烈倾向于缓存到磁盘。毕竟，磁盘空间很便宜，而加载时间就是 Web 上的一切。即使您只是以特定大小缓存缩略图并在其他任何地方进行动态调整大小，您也可以大大减少画廊风格图像列表的加载时间。
于 2010-05-13T00:04:46.290 回答
17
这听起来像是过早的优化。您知道您的网站将拥有多少用户/您的服务器将拥有多少计算任务？使用最简单（维护方面）的选项，即动态调整大小，直到性能成为问题，然后从那里弄清楚该怎么做。
如果它们可能会被反复击中，那么对重新缩放的图像实施某种服务器端缓存可能是一个想法，但我认为这种需要不会扩展到显式预渲染。
于 2010-05-13T00:00:18.983 回答
17
我强烈建议您缓存您的图像，而不是即时调整大小。
调整图像大小对您的服务器来说非常消耗 CPU 和内存。
如果您有一个要即时缩放的图片库，则页面将缓慢加载图片，例如 3-10 秒，具体取决于原始文件大小。
调整大小时，大约需要 3 个字节 pr 像素的内存。所以如果你有一个 1000x1000 的图像要调整大小，大约需要 3MB 的内存。如果您的一个网页有许多这样的动态调整大小的图像，比如 20 个，则它将占用您服务器的大约 60MB 内存。也许不是，因为大多数客户端当时只请求 4 张图片，但 12MB 对于页面加载来说仍然很多。如果源图像小于 100x100 像素，我只会动态缩放。
提示： PhpThumb是一个很好的缩放和保存拇指的库
于 2010-05-13T00:22:26.500 回答