我一直在寻找一种更好的方法来处理这种情况,所以我使用了一些在互联网上找到的不同功能。
总的来说,当它起作用时,最快的往往是 James Relyea 在 PHP 页面上为 getimagesize 发布的 getjpegsize 函数,击败了上面 Dejan 提供的 ranger 函数。
http://php.net/manual/en/function.getimagesize.php#88793
Image #1 (787KB JPG on external older server)
getimagesize: 0.47042 to 0.47627 - 1700x2340 [SLOWEST]
getjpegsize: 0.11988 to 0.14854 - 1700x2340 [FASTEST]
ranger: 0.1917 to 0.22869 - 1700x2340
Image #2 (3MB PNG)
getimagesize: 0.01436 to 0.01451 - 1508x1780 [FASTEST]
getjpegsize: - failed
ranger: - failed
Image #3 (2.7MB JPG)
getimagesize: 0.00855 to 0.04806 - 3264x2448 [FASTEST]
getjpegsize: - failed
ranger: 0.06222 to 0.06297 - 3264x2448 * [SLOWEST]
Image #4 (1MB JPG)
getimagesize: 0.00245 to 0.00261 - 2031x1434
getjpegsize: 0.00135 to 0.00142 - 2031x1434 [FASTEST]
ranger: 0.0168 to 0.01702 - 2031x1434 [SLOWEST]
Image #5 (316KB JPG)
getimagesize: 0.00152 to 0.00162 - 1280x720
getjpegsize: 0.00092 to 0.00106 - 1280x720 [FASTEST]
ranger: 0.00651 to 0.00674 - 1280x720 [SLOWEST]
-
ranger 在 Image #3 上抓取 32768 字节时失败,所以我将其增加到 65536,它成功抓取了大小。
但存在一些问题,因为ranger 和getjpegsize 都受到限制,使其不够稳定,无法使用。在处理大约 3MB 的大型 JPG 图像时两者都失败了,但 ranger 在更改它抓取的字节数后将起作用。此外,这些替代只处理 JPG 图像,这意味着需要使用条件来仅在 JPG 上使用它们,而在其他图像格式上使用 getimagesize。
另外,请注意,第一个图像位于运行旧版本 PHP 5.3.2 的旧服务器上,而其他 4 个图像来自现代服务器(具有 MultiPHP 的基于云的 cPanel 拨回 5.4.45 以实现兼容性)。
值得注意的是,基于云的服务器在getimagesize 上的表现要好得多,它击败了ranger,事实上,在云服务器上的所有4 个测试中,ranger 是最慢的。这 4 个人也在代码运行时从同一服务器提取图像,但帐户不同。
这让我想知道 PHP 核心是否在 5.4 中得到了改进,或者 Apache 版本是否有所改进。此外,这可能取决于服务器和服务器负载的可用性。我们不要忘记网络每年都在变得越来越快,因此速度问题可能正在变得不那么令人担忧。
所以,最终结果和我的回答是,为了完全支持所有 Web 图像格式,并且仍要实现超快的图像大小,最好将其吸收并使用 getimagesize,然后缓存图像大小(如果将多次检查这些图像)在数据库表中。在这种情况下,只有第一次检查会产生更大的成本,但随后的请求将比读取图像标题的任何函数最小且更快。
与任何缓存一样,它只有在内容没有发生变化并且有办法检查是否发生变化时才能正常工作。因此,一种可能的解决方案是在检查缓存时仅检查图像 URL 的标头,如果不同,则转储缓存版本并使用 getimagesize 再次获取它。