PHP 图像动态调整大小与存储调整大小的图像

这绝对是无可比拟的事情。

事实上，动态调整图像大小就像在您自己的服务器上运行DoS攻击一样。调整一个常用映像的大小需要更多的 CPU 和 RAM，而不是为 php 脚本提供一个常用请求。这已经对性能产生了巨大的影响。然而，通常的缩略图不是单独显示的，而是以数字形式显示的。因此，虽然只显示一个图库页面，但您正在创建数十个重负载进程，从而使服务器负载增加十倍或更多。

快速和肮脏的测试来证明我的话：让我们尝试调整相对较小的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，01s。因此，随着您动态调整大小，您将服务器负载增加100倍。

内存也是如此。每个调整大小过程将消耗不少于10M的内存（以调整100k图像文件的大小！），总和为100M。虽然PHP脚本的通常内存限制仅为8M，但很少达到。

这是现实生活中的数字。

与这个问题相关的一件有点有趣的事情：
正是同一个PHP用户，他们很容易丢弃1000000个CPU周期，同时又非常嫉妒地节省1或2个！这不是一个语音数字，这里有一个关于我正在谈论的例子：
来自某人的类似问题，他非常关注常量，变量或变量数组之间的速度差，同时又可以忽略不计。而谁最近遇到了允许内存大小耗尽的问题，好像这样的灾难是不够的。

这个网站上有大量的问题和答案，辩论任何操作的纳秒速度差异，以取之不尽用之不竭的尊严回答，运行数百万次迭代的测试，以显示每个CPU周期的一次性操作之间的差异绝对可以忽略不计。

与此同时，也存在这样的问题 - 关于两种方法之间在性能方面的巨大，无与伦比的差异，这看起来与作者完全相同。

这就是普通PHP用户和这个网站的问题。
前者只是没有措施来区分真实的东西和微观的东西。
然而，后者没有对问题进行理智检查的机制 - 每个人都以同样的热情回答，即使两个问题相互矛盾（并且都与常识相矛盾）。

动态调整大小可能是一个代价高昂的过程（按时间而言），具体取决于图像的初始大小。我已经在生产系统中做到了这一点，但是当我有选择时，我强烈支持缓存到磁盘。毕竟，磁盘空间很便宜，加载时间就是Web上的一切。即使您只是以特定大小缓存缩略图并在其他任何地方进行动态调整大小，也可以大大减少画廊样式图像列表的加载时间。