PHP 动态调整图像大小与存储调整大小的图像
我正在构建一个图像共享网站，想了解使用 PHP 动态调整图像大小并存储调整后的图像的优缺点。
哪个更快？
哪个更可靠？
两种方法在速度和性能上差距有多大？
请注意，无论哪种方式，图像都会通过 PHP 脚本进行统计（例如视图），或者是否允许热链接等...因此，如果我选择存储调整大小的图像，它就不会是图像的直接链接。
我将感谢您的评论或有关该主题的任何有用的链接。
I'm building a image sharing site and would like to know the pros and cons of resizing images on the fly with PHP and having the resized images stored.
Which is faster?
Which is more reliable?
How big is the gap between the two methods in speed and performance?
Please note that either way the images go through a PHP script for statistics like views or if hotlinking is allow etc... so is not like it will be a direct link for images if I opt to store the resize images.
I'll appreciated your comments or any helpful links on the subject.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这绝对是无与伦比的事情。
动态调整图像大小，实际上就像在您自己的服务器上运行 DoS 攻击一样。调整一张常用图像的大小比为 php 脚本提供一个常用请求需要更多的 CPU 和 RAM。这已经对性能产生了巨大影响。然而，通常的缩略图不是单独显示，而是以数字形式显示。因此，虽然只显示一个图库页面，但您正在创建数十个重负载进程，从而使服务器负载增加十倍或更多。
快速而肮脏的测试来证明我的话：
让我们尝试调整相对较小的 1.3 兆像素图像的大小，
这花了我们 0.1 秒的时间，因此，显示 10 个图像预览将占用整整一秒的 CPU 时间。正确编写 PHP 画廊页面大约需要 0.01 秒。因此，当您动态调整大小时，服务器负载会增加 100 倍。
内存也是如此。每个调整大小过程将占用不少于 10M 的内存（调整 100k 图像文件的大小！），总计 100M。而PHP脚本通常的内存限制仅为8M，而且很少达到。
那是现实生活中的数字。
与这个问题相关的一件有点有趣的事情：
完全是同一个 PHP 用户，他轻松地丢弃了 1000000 个 CPU 周期，同时又难以置信地嫉妒节省 1 或 2 个 CPU 周期！这不是一种修辞手法，这里有一个例子来说明我正在谈论的内容：
来自某人的类似问题，他的很棒同时关注速度差异可以忽略不计常量、变量或变量数组之间。最近遇到了允许的内存大小耗尽问题，好像这样的灾难还不够。
这个网站上有大量的问题和答案，争论任何操作的纳秒速度差异，并以无尽的尊严回答，运行数百万次迭代的测试，以显示每个 CPU 周期的一次性操作之间的差异绝对可以忽略不计。
同时也存在这样的问题——两种方法在性能方面存在巨大的、无可比拟的差异，而这在作者看来只是相同的。
这就是普通 PHP 用户和这个网站的问题。
前者只是没有办法区分真实事物和微观事物。
然而，后者没有对问题进行健全性检查的机制 - 每个人都以同样的热情回答，即使两个问题彼此矛盾（并且都具有常识）。
This is absolutely incomparable matters.
Resizing images on the fly, in fact, is like running a DoS attack on your own server. Resize of one usual image require more CPU and RAM than serving one usual request to php script. That's ALREADY a huge impact on performance. Yet a usual thumbnail being shown not alone, but in numbers. So, while showing only one gallery page you are creating dozens of heavy load processes, increasing server load by a factor of ten or more.
Quick and dirty test to prove my words:
Let's try to resize relatively small, 1,3 megapixel image
It took us 0,1s, so, showing 10 image previews will eat up a whole second of your CPU time. While properly written PHP gallery page will take around 0,01s. So, with your resize on the fly you are increasing the server load by a factor of 100.
Same with memory. Each resize process will eat no less than 10M of memory (to resize a 100k image file!) with a total sum of 100M. While usual memory limit for the PHP script is merely 8M and it is seldom reached.
That are the real life numbers.
A somewhat funny thing related to this problem:
Exactly the same PHP user who easily throwing away 1000000s of CPU cycles at the same time being incredible jealous to spare 1 or 2! It is not a figure of speech, here is an example on what I am talking about:
A similar question from someone, whose great concern at the same time in as negligible thing as speed difference between Constants, Variables or Variable Arrays. And who recently run into allowed memory size exhausted problem, as though such a disaster was not enough.
There are TONS of questions and answers on this site, debating nanosecond speed difference of whatever operations, answered with inexhaustible dignity, running tests of millions of iterations to show absolutely negligible difference between one-shot operations of several CPU cycles each.
And at the same time there are questions like this - regarding huge, incomparable difference in terms of performance between two approaches, which looks merely equal to the author.
That's the problem with average PHP user and this site.
The former just have no measure to tell real things from microscopic ones.
Yet the latter have no mechanism for sanity check for the questions - every one answered with equal enthusiasm, even if two questions contradicts with each other (and both with common sense).
动态调整大小可能是一个成本高昂的过程（时间方面），具体取决于图像的初始大小。我已经在生产系统中做到了这一点，但是当我有选择时，我强烈支持缓存到磁盘。毕竟，磁盘空间很便宜，而加载时间在网络上就是一切。即使您只是以特定大小缓存缩略图并在其他地方动态调整大小，也可以大大减少图库样式图像列表的加载时间。
Dynamic resizing can be a costly procedure (time-wise) depending on the initial size of the images. I've done it in production systems, but when I have the choice, I strongly favor caching to disk. After all, disk space is cheap, and load time is everything on the Web. Even if you simply cache thumbnails at a specific size and do dynamic resizing everywhere else, you can greatly reduce loading times for gallery-style image lists.
这听起来像是过早的优化。您知道您的网站将有多少用户/您的服务器将有多少计算量吗？采用最简单的（维护方面的）选项，即动态调整大小，直到性能成为问题，然后从那里找出要做什么。
如果重新缩放的图像可能会被重复命中，那么对它们进行某种服务器端缓存可能是一个想法，但我认为这不需要扩展到显式预渲染。
This sounds like premature optimisation. Do you know how many users your site will have/ how much computational grunt your server(s) will have? Go with the simplest (maintenance-wise) option, i.e. resize on the fly, until performance becomes an issue, then figure out from there what to do.
It might be an idea to implement some sort of server side caching of your rescaled images, if they're likely to be repeatedly hit, but I don't think this need extend as far as explicit pre-rendering.
我强烈建议您缓存图像，而不是即时调整大小。
调整图像大小非常消耗服务器的 CPU 和内存。
如果您有一个要动态缩放的图像库，则页面会缓慢加载图像，例如 3-10 秒，具体取决于原始文件大小。
调整大小时，每像素大约需要 3 个字节的内存。因此，如果您有一个 1000x1000 的图像需要调整大小，则大约需要 3MB 内存。如果您的某个网页包含许多此类即时调整大小的图像（例如 20 个），则将占用服务器大约 60MB 的 RAM。
也许不会，因为大多数客户端一次只请求 4 个图像，但 12MB 对于页面加载来说仍然很大。如果源图像小于 100x100 像素，我只会动态缩放。
提示：用于缩放和保存拇指的一个很棒的库是 PhpThumb
I strongly advice you to cache your images, and NOT resize on-the-fly.
resizing of images is very CPU intensive and memory consuming for your server.
If you have a gallery of images that is going to scale on the fly, the page is going to load the images slowly, say something like 3-10 seconds, depends on original filesize.
When resizing it takes about 3 bytes pr pixel of your memory. So If you have an image 1000x1000 to be resized, it will take about 3MB of memory. If your one of your webpages has many of these resize-on-the-fly images, say 20, it will take about 60MB of RAM of your server.
Maybe not, since most clients only requests 4 images at the time, but 12MB is still a lot for a pageload. I would only scale on the fly if the source image is less that 100x100 px.
TIP: A great lib for scaling and saving thumbs is PhpThumb