缓存，PHP 生成的缩略图加载缓慢答案

【问题标题】：Cached, PHP generated Thumbnails load slowly缓存，PHP 生成的缩略图加载缓慢
【发布时间】：2011-06-16 04:45:18
【问题描述】：

问题 A 部分 ▉（奖励 100 次）
主要问题是如何使这个网站加载更快。首先，我们需要阅读这些瀑布。感谢大家对瀑布读数分析的建议。从这里显示的各种瀑布图中可以看出主要瓶颈：PHP 生成的缩略图。 David 建议的从 CDN 加载的无协议 jquery 得到了我的赏金，尽管它使我的网站总体上只快了 3%，而且没有解决网站的主要瓶颈。是时候澄清我的问题了，还有另一个赏金：

问题 B 部分 ▉（100 个赏金，已获奖）
现在的新重点是解决 6 jpg 图像所存在的问题，这些问题导致大部分加载延迟。这 6 张图片是 PHP 生成的缩略图，很小，只有 3~5 kb，但加载速度相对非常慢。请注意各种图表上的“第一个字节的时间”。问题仍未解决，但 James 得到了赏金，他修复了 RedBot underlined 的标头错误：“If-Modified-Since 条件请求返回完整内容不变。”。

问题 C 部分 ▉（我最后的赏金：250 分）
不幸的是，在修复了 REdbot.org 标头错误之后，由 PHP 生成的图像引起的延迟仍然没有改变。这些微小的 3~5Kb 缩略图到底在想什么？所有这些标题信息都可以将火箭发送到月球并返回。非常感谢有关此瓶颈的任何建议并将其视为可能的答案，因为我已经被这个瓶颈问题困扰了七个月了。

[我网站上的一些背景信息：CSS 位于顶部。底部的 JS（Jquery、JQuery UI、购买的菜单 awm/menu.js 引擎、标签 js 引擎、视频 swfobject.js）第二张图片上的黑线显示了启动加载的内容。愤怒的机器人是我的宠物“ZAM”。他是无害的，而且常常更快乐。]

加载瀑布：时间顺序 | http://webpagetest.org

并行域分组 | http://webpagetest.org

Site-Perf 瀑布 | http://site-perf.com

Pingdom 工具瀑布 | http://tools.pingdom.com

GTmetrix 瀑布 | http://gtmetrix.com

【问题讨论】：

我认为大多数浏览器一次只能建立 20 个连接，所以在 20 个之后第一个必须在下一个开始之前完成，因此在 20 之后会变慢
我认为您忘记编辑您的域的第一个实例。至少你得到了其余的：D
你不能将其中一些图像组合成精灵吗？
@Dagon，请注意HTTP 1.1 RFC 要求 (SHOULD) HTTP 1.1 客户端最多使用 2 个与 HTTP 1.1 服务器的连接； HTTP 1.0 当然更开放。
@Dagon 浏览器也只会与任何给定域建立 2 个并发连接。

标签： php performance .htaccess cache-control

【解决方案1】：

哇，用那张图片很难解释。但是在这里，一些尝试：

文件 33-36 加载较晚，因为它们是在 swf 中动态加载的，并且 swf (25) 在加载任何其他内容之前首先完全加载
文件 20 和 21 是也许（我不知道，因为我不知道你的代码）由 all.js (11) 加载的库，但要执行 11，它等待整个页面（和资产）加载（您应该将其更改为 domready）
文件 22-32 由这两个库加载，在完全加载之后再次加载

【讨论】：

有趣的地方。我猜 swf 周围什么都没有……我怎样才能改变 domready 的内容？我有预感你的意思。它是关于 javascript 何时准备好并告诉文档准备好这个或那个？应该将 document.ready 替换为 dom.ready 吗？
@Sam 如果您正在使用客户端缓存（并且您应该使用），您可以在 js 中加载 swf 使用的资源或页面上的隐藏 div，以便当 swf 请求它们时已经在客户端了。

【解决方案2】：

只是一个简单的猜测，因为这种分析需要大量的 A/B 测试：您的 .ch 域似乎很难到达（第一个字节到达之前的长长的绿色条带）。

这意味着 .ch 网站的托管状况不佳，或者您的 ISP 没有通往它们的良好路径。

鉴于图表，这可以解释一个巨大的性能损失。

附带说明一下，有一个很酷的工具cuzillion 可以帮助您根据资源加载的顺序来解决问题。

【讨论】：

【解决方案3】：

尝试在您的网站/页面上运行 Y!Slow 和 Page Speed 测试，并按照指南排除可能的性能瓶颈。一旦您在 Y!Slow 或 Page Speed 中得分较高，您应该会获得巨大的性能提升。

这些测试会告诉您哪里出了问题以及需要改变什么。

【讨论】：

谢谢！分数是：Page Speed 92 分，Ylow 93 分。缺少的是：KEEP ALIVE = 关闭且不使用 CDN。
更新：目前分别为 96 和 90

【解决方案4】：

首先，使用这些多个域需要多次 DNS 查找。你最好combining many of those images into a sprite 而不是传播请求。

其次，当我加载您的页面时，我在 all.js 上看到了大部分阻塞（约 1.25 秒）。我看到它以（旧版本的）jQuery 开头。您应该从 Google CDN 引用它，不仅要引用 decrease load time，还要完全引用 potentially avoid an HTTP request for it。

具体来说，最新的 jQuery 和 jQuery UI 库可以在这些 URL 中引用（如果您有兴趣，请参阅this post，为什么我省略了http:）：

//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js

//ajax.googleapis.com/ajax/libs/jqueryui/1.8.9/jquery-ui.min.js

如果您使用默认的 jQuery UI 主题之一，您也可以pull its CSS and images off the Google CDN。

优化 jQuery 托管后，您还应该将 awmlib2.js 和 tooltiplib.js 合并到一个文件中。

如果你解决了这些问题，你应该会看到显着的改进。

【讨论】：

优秀的评论戴夫！旧的 1.3 JQuery 要小得多，所以我想在它工作的时候，它可能会更快。但我喜欢你的建议：你建议我使用哪个 google CDN 链接作为我的 Jqyuery？我可以使用相同的方式 JQ UI javascript 吗？ +1 非常感谢
我绝对推荐使用最新版本的 jQuery（目前为 1.4.4）。当缩小和压缩时，它们之间只有几个字节的差异。我已经通过几个链接更新了答案，这些链接指向 Google CDN 上的最新 jQuery 和 jQuery UI 版本，我建议使用它们。
精灵的好提示，应该减少与服务器的打开连接数
目前正在努力减少打开的连接（从 40 左右到现在 30 左右......最后的推动是最困难的，因为一些图像正在重复背景并且无法进入精灵（或???)
更新页面速度等级：(96%) YSlow 等级：(90%) ...但缩略图仍然像以前一样慢！

【解决方案5】：

几天前我遇到了类似的问题，我找到了head.js。它是一个 Javascript 插件，允许您并行加载所有 JS 文件。希望对您有所帮助。

【讨论】：

难以置信！我怎么能忽略这一点？ +1 我现在要测试这个。闻起来像一个富有成果的夜晚。谢谢 Schattenbaum！
请问你是不是来自 schattenbaum.net 的 Schattenbaum？

【解决方案6】：

所以您的 PHP 脚本会在每次页面加载时生成缩略图？首先，如果缩略图的图像不经常更改，您是否可以设置一个缓存，以便在每次页面加载时都不必解析它们？其次，您的 PHP 脚本是否使用 imagecopyresampled() 之类的东西来创建缩略图？这是一个不平凡的下采样，PHP 脚本在完成缩小之前不会返回任何内容。改用imagecopymerged() 会降低图像质量，但会加快处理速度。你做了多少减少？这些缩略图是原始图像大小的 5% 还是 50%？原始图像的较大尺寸可能会导致速度变慢，因为 PHP 脚本必须先将原始图像放入内存中，然后才能缩小它并输出较小的缩略图。

【讨论】：

感谢午夜闪电！有一个缓存文件夹，从中创建和重用缩略图 JPG，尽管我觉得这里存在我购买的脚本的问题（并且似乎对其他人工作正常）
如果缩略图被缓存，请确保从缓存中提取它们的脚本使用readfile() 而不是file_get_contents() 后跟一个回显，它会等待输出任何内容，直到将整个文件移入PHP 脚本的内存。
更好的是——如果文件被缓存，生成 HTML 的方式是直接从磁盘中提取缓存的图像而不通过 PHP。这就是我在 videodb.net 的脚本中所做的事情
“有一个缓存文件夹在哪里...”以及它们被取消引用的速度有多快？您的 URL 是直接指向缓存文件还是 PHP 脚本？您是重定向还是使用 readfile()？相同的 PHP 脚本是否包含缩略图生成代码 - 或者您是否使用 include/erquire 延迟加载大部分代码？

【解决方案7】：

我远非专家，但...

关于这个： “一个 If-Modified-Since 条件请求返回完整内容不变。” 还有我的cmets。

用于生成缩略图的代码应检查以下内容：

是否有缩略图的缓存版本。
缓存版本是否比原始图像新。

如果其中任何一个为 false，则无论如何都应生成并返回缩略图。如果它们都为真，则应进行以下检查：

是否有 HTTP_IF_MODIFIED_SINCE 标头
缓存版本的最后修改时间是否与HTTP_IF_MODIFIED_SINCE相同

如果其中任何一个为假，则应返回缓存的缩略图。

如果这两个都为真，则应返回 304 http 状态。我不确定它是否需要，但我也亲自返回 Cache-Control、Expires 和 Last-Modified 标头以及 304。

关于 GZipping，我已被告知无需对图像进行 GZip，因此请忽略我评论的那部分。

编辑：我没有注意到您对帖子的添加。

session_cache_limiter('public');
header("Content-type: " . $this->_mime);
header("Expires: " . gmdate("D, d M Y H:i:s", time() + 2419200) . " GMT");
// I'm sure Last-Modified should be a static value. not dynamic as you have it here.
header("Last-Modified: " . gmdate("D, d M Y H:i:s",time() - 404800000) . " GMT");

我还确定您的代码需要检查 HTTP_IF_MODIFIED_SINCE 标头并对其做出反应。仅设置这些标头和您的 .htaccess 文件不会提供所需的结果。

我认为你需要这样的东西：

$date = 'D, d M Y H:i:s T'; // DATE_RFC850
$modified = filemtime($filename);
$expires = strtotime('1 year'); // 1 Year

header(sprintf('Cache-Control: %s, max-age=%s', 'public', $expires - time()));
header(sprintf('Expires: %s', date($date, $expires)));
header(sprintf('Last-Modified: %s', date($date, $modified)));
header(sprintf('Content-Type: %s', $mime));

if(isset($_SERVER['HTTP_IF_MODIFIED_SINCE'])) {
    if(strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) === $modified) {
        header('HTTP/1.1 304 Not Modified', true, 304);
        // Should have been an exit not a return. After sending the not modified http
        // code, the script should end and return no content.
        exit();
    }
}
// Render image data

【讨论】：

詹姆斯您在编辑答案后抓住了问题的本质！ If Modified Since 问题现在似乎有效！然而，小拇指的长标题/等待时间还没有解决......
@James PS REdbot.org 说您的 Expires 标头的值不正确。我认为它必须是 GMT 而不是 CET？
@Sam 对不起，我的服务器在英国，所以它会自动生成 GMT 日期。如果日期，只需使用 PHP 函数 gmdate 代替。这应该会产生一个相对于您的服务器时间的 GMT 日期。
@Sam，您的等待时间就是脚本执行时间。它要么需要很长时间才能通过您的代码来发送您的标头，要么您在发送标头后没有退出。
@James，我明白了...但是除了那个 php 缩略图生成器之外，还有很多其他等长的脚本可以执行各种其他操作（翻译、菜单加载等）。一小部分时间......他们似乎根本没有遇到瓶颈......这是否将问题引向缩略图生成器 php？

【解决方案8】：

首先，正如詹姆斯所说，您需要适当地处理If-Modified-Since 请求等。该错误表明：“当我询问您的服务器自上次以来该图像是否被修改时，它会发送整个图像而不是简单的是/否”。

连接和第一个字节之间的时间通常是您的 PHP 脚本运行所需的时间。很明显，当该脚本开始运行时，正在发生一些事情。

您是否考虑过对其进行概要分析？它可能存在一些问题。
结合上述问题，您的脚本运行的次数可能比需要的多得多。理想情况下，它应该仅在原始图像被修改并为每个其他请求发送缓存的拇指时生成拇指。您是否检查过脚本生成了不必要的图像（例如，对于每个请求）？

通过应用程序生成正确的标头有点棘手，而且它们可能会被服务器覆盖。而且您会受到滥用，因为任何发送一些无缓存请求标头的人都会导致您的缩略图生成器连续运行（并增加负载）。因此，如果可能，请尝试保存这些生成的缩略图，直接从您的页面调用保存的图像并从.htaccess 管理标题。在这种情况下，如果您的服务器配置正确，您甚至不需要 .htaccess 中的任何内容。

除此之外，您还可以从how to do websites the right way 上这个整体不错的 SO 问题的性能部分应用一些出色的优化想法，例如将您的资源拆分为无 cookie 的子域等。但无论如何，3k 图像应该无需花费一秒钟的时间来加载，与图表中的其他项目相比，这一点很明显。您应该在优化之前尝试发现问题。

【讨论】：

-1：在 99.9% 的情况下，使用“未修改”响应条件请求且未修改过期时间会使您的网站变慢（顺便说一句，AFAIK，无法让 Apache 发布使用 304 响应修改缓存信息）
而且，这与我的回答有什么关系？

【解决方案9】：

调查 PHP 对会话数据的使用。也许（只是也许），生成图像的 PHP 脚本正在等待锁定会话数据，该会话数据被仍在渲染的主页或其他图像渲染脚本锁定。这将使所有 JavaScript/浏览器优化几乎无关紧要，因为浏览器正在等待服务器。

PHP 为每个运行的脚本锁定会话数据，从会话处理开始到脚本完成，或者在调用 session_write_close() 时。这有效地序列化了事物。查看有关会话的 PHP 页面，尤其是 cmets，例如 this one。

【讨论】：

感谢里卡多的建议！似乎 Alix 的建议与您相同（对吗？）。实际上，您建议我从代码中放置/删除什么，然后再次测试图表然后报告回来？非常感谢。
是的，我想是的。我建议您更改图像生成脚本，以便它们不依赖于 $_SESSION 数据或类似数据（也许它们已经不依赖）。然后尽快使用 session_write_close()，或者更好的是，完全避免在这些脚本上使用会话。查看php.net/manual/en/function.session-write-close.php

【解决方案10】：

您是否尝试在NGINX webserver 下设置几个子域，专门用于提供图像和样式表等静态数据？ in this topic 已经找到了一些有用的东西。

【讨论】：

谢谢！然而，经过一些研究，似乎将子域设置为服务器静态 cookie 只会使网站更快，当有很多图像时，会产生一些额外的开销。就我而言，我打赌这 6 个图像的加载速度不会比子/额外域的开销快。对吗？
NGinx 支持 sendfile 系统调用，可以直接从硬盘发送文件。请参阅以下文档 wiki.nginx.org/HttpCoreModule 关于指令“sendfile”、“aio”。该网络服务器提供静态文件（如图像）比 apache 快得多。
很有趣...我不知道还有什么比 Apache 更好的。顺便说一句，straight from hdd 是什么意思。你的意思是straight from DDR3 RAM / straight from Solid State Disk 我确实知道硬盘与 DDR3 内存或固态磁盘不同，访问时间非常慢。但我觉得这不是这里的瓶颈......
重点是nginx不像apache那样缓冲静态数据输出。

【解决方案11】：

我找到了您网站的 URL，并检查了主页上的单个 jpg 文件。虽然现在加载时间（161 毫秒）是合理的，但它等待 126 毫秒，这太长了。

您最后修改的标题都设置为 2011 年 1 月 1 日星期六 12:00:00 GMT，这看起来太“圆”而不是真正的生成日期 ;-)

由于 Cache-control 是“public, max-age=14515200”，任意 last-modified headers 可能会在 168 天后导致问题。

无论如何，这不是延误的真正原因。

当缩略图已经存在时，您必须检查缩略图生成器会做什么，以及检查和交付图片会消耗这么多时间。

您可以安装xdebug 来分析脚本并查看瓶颈在哪里。

也许整个事情都使用了一个框架或连接到某个数据库。我在某些服务器上看到 mysql_connect() 非常慢，主要是因为它们使用 TCP 而不是套接字进行连接，有时会出现一些 DNS 问题。

我知道你不能在这里发布你的付费发电机，但我担心有太多可能的问题......

【讨论】：

感谢您的侦探和线索胶囊！首先要做的事情：没有数据库。你的发现和我的一样：它等待 90% 的时间是为了什么？疯狂的小拇指。关于 last-modified 标头的有趣想法，因为根据 James post here，我必须将这些 Last-modified 标头设置为 STATIC（固定）时间，而不是由 php gmdate 生成器设置的动态/始终更改时间。或者你的意思是别的什么？（获得赏金提名）
为了完美，它应该反映真实的生成日期，例如通过获取缓存缩略图的 filemtime()。有趣的测试是访问一个空的 PHP 文件，或者一个只是回显“test”的 PHP 文件，看看你在这个文件上等待了多少。也许整个服务器很慢并且影响到每一个 PHP 脚本，不管它做什么。
我还看到纯静态文件（例如链接到拇指的图像）的延迟相对较长，例如 36 毫秒。在我正在管理的其中一台服务器上（这不是野兽......双核，2Gb RAL），我几乎得到了一半，比如静态文件上的 20 毫秒。
有趣... 1.您使用什么软件/在线工具进行测量？ 2. 您的更快的 20 毫秒测量值是否一致（多少 ± xx%）您是否发现您的结果有所不同？就我而言，这取决于我使用的测试工具。有些非常一致（gtmetrix.com）有些非常不同（pingdom.com）并且很难以 XX 毫秒为单位给出时间，因为它们每次都会改变......
我正在使用 Firebug 的 NET 标签。 20ms 是我得到的最快时间。它在 20 到 28 之间变化。当然，我在您的服务器上测量的 36 毫秒也是最快的。

【解决方案12】：

如果没有很好的理由（通常没有），您的图像不应调用 PHP 解释器。

为您的网络服务器创建一个重写规则，如果在文件系统上找到该图像，则该规则会直接为其提供服务。如果不是，请重定向到您的 PHP 脚本以生成图像。编辑图像时，更改图像文件名以强制具有缓存版本的用户获取新编辑的图像。

如果它不起作用，至少你现在会觉得它与创建和检查图像的方式没有任何关系。

【讨论】：

感谢 Goran，但这不是我想要的优雅解决方案：我认为我的情况有些可疑，通常 php 脚本真的不需要很长时间才能知道是否通过 304 标头或烘焙图像等。无论如何感谢您的建议，因为它从一个全新的角度指导问题！这本身就有价值+1

【解决方案13】：

您是否尝试过用常规图像替换 php 生成的缩略图，看看有什么不同？问题可能在附近 - 您的 php 代码中的错误导致每次服务器调用时缩略图的重新生成 - 与时钟问题相关的代码延迟（sleep()?） - 硬盘驱动器问题导致非常糟糕的竞态条件，因为所有缩略图同时加载/生成。

【讨论】：

我曾经想过尝试 +1 以阅读我的想法并揭示我已经做过的第一个解决方案。我希望的是，发现正常图像也会加载缓慢，因此可能是下载带宽速度或物理限制，但我发现正常的静态转储图像（我保存生成的拇指并上传为静态）这些加载非常快。所以它与缩略图生成器php有关！

【解决方案14】：

关于延迟的缩略图，请尝试在缩略图生成脚本中最后一次调用header() 之后立即调用flush()。完成后，重新生成您的瀑布图并查看延迟现在是否在正文而不是标题上。如果是这样，您需要仔细查看生成和/或输出图像数据的逻辑。

处理缩略图的脚本应该希望使用某种缓存，以便它对您所提供的图像执行的任何操作都只会在绝对必要时发生。每次您提供缩略图时似乎都会发生一些昂贵的操作，这会延迟脚本的任何输出（包括标题）。

【讨论】：

+1 令人兴奋的猜测，现在就来试试吧！当我有新的瀑布流动时会报告......
不幸的是，在标题后添加flush(); 之后，似乎根本没有任何变化！这意味着什么？
不确定。有什么方法可以将我们链接到有问题的 PHP 脚本？我知道您为此付出了代价，但是如果无法看到它在做什么，就很难说出可能导致该行为的原因。
缩略图是在 CSS 中还是在标签中引用的？
在css中引用是什么意思？它们在正文 html 中，如下所示：<img src="thumbprocessor.php?src=/folder/image.jpg&w=100&h=200" id="thumbnail"/>

【解决方案15】：

我认为，您必须尝试使用TinySRC，而不是使用那个缩略图生成器脚本，以便快速快速地生成云托管缩略图。它有一个非常简单易用的 API，你可以像这样使用：-

http://i.tinysrc.mobi/ [高度] / [宽度] /http://domain.tld/path_to_img.jpg

[宽度]（可选）：- 这是一个以像素为单位的宽度（覆盖自适应或系列大小）。如果以“-”或“x”为前缀，它将减去或缩小到确定大小的百分比。

[身高]（可选）：- 这是一个以像素为单位的高度，如果宽度也存在的话。它还覆盖自适应或家庭大小，并且可以使用“-”或“x”作为前缀。

您可以查看API摘要here

FAQ

tinySrc 花了我多少钱？

什么都没有。

什么时候可以开始使用 tinySrc？

现在。

服务的可靠性如何？

我们对 tinySrc 服务不做任何保证。但是，它在大型分布式云基础架构上运行，因此它在全球范围内提供高可用性。它应该足以满足您的所有需求。

有多快？

tinySrc 将调整大小的图像缓存在内存和我们的数据存储中长达 24 小时，它不会每次都获取您的原始图像。从用户的角度来看，这使得服务非常快。（并减少您的服务器负载作为一个很好的副作用。）

祝你好运。只是一个建议，因为你没有向我们展示代码：p

【讨论】：

【解决方案16】：

这只是一个疯狂的猜测，因为我没有查看您的代码，但我怀疑会话可能在这里发挥了作用，以下来自session_write_close() 上的 PHP 手册条目：

会话数据通常存储在您的脚本在没有需要调用 session_write_close()，但由于会话数据被锁定到防止并发写入只有一个脚本可以在任何时间对会话进行操作时间。一起使用框架集时通过课程，您将体验到由于这个原因，帧一一加载锁定。 您可以减少时间需要加载所有帧尽快结束会议会话变量的更改是完成。

就像我说的，我不知道您的代码在做什么，但这些图表看起来非常可疑。当I coded a multipart file serving function 和我遇到同样的问题时，我遇到了类似的问题。提供大文件时，我无法使用多部分功能，也无法打开另一个页面，直到下载完成。 Calling session_write_close() fixed 都是我的问题。

【讨论】：

感谢 Alix 的建议。一个问题：exit(); 函数是否与session_write_close(); 类似？目前，代码的原始作者正在调查这个问题，但是他似乎也有点不知所措，因为他用更好的 If-Modified-Since 处理来慷慨更新代码似乎有同样的延迟（新瀑布图表产生了相同的图表，虽然真实世界的结果看起来/感觉更快的加载！这是一个非常奇怪的问题......
@Sam：我现在不能给你任何消息来源，但我相信 exit() 首先调用任何为关闭而注册的析构函数和/或函数，然后才关闭会话。无论如何，我敢打赌，您的问题可能出在您的 exit() 调用之前。另见：stackoverflow.com/questions/1674314/…

【解决方案17】：

很抱歉，您提供的数据很少。而且您已经提出了一些很好的建议。

您如何提供这些图片？如果您通过 PHP 流式传输这些内容，那么即使它们已经生成，您也是在做一件非常糟糕的事情。

永远不要使用 PHP 流式传输图像。无论您以何种方式使用它，它都会降低您的服务器速度。

将它们放在一个可访问的文件夹中，并带有一个有意义的 URI。然后直接使用它们的真实 URI 调用它们。如果您需要即时生成，您应该在图像目录中放置一个 .htaccess，仅当请求图像丢失时才会重定向到生成器 php-script。（这称为缓存请求策略）。

这样做将一次性修复 php 会话、浏览器代理、缓存、ETAGS 等等。

如果配置正确，WP-Supercache 会使用此策略。

我前段时间写了这篇文章（http://code.google.com/p/cache-on-request/source/detail?r=8），最后的修订版被破坏了，但我想 8 或更少应该可以工作，你可以拿 .htaccess 作为一个例子来测试一下（尽管有更好的方法来测试配置 .htaccess 比我以前的方式）。

我在这篇博文 (http://www.stefanoforenza.com/need-for-cache/) 中描述了该策略。它可能写得不好，但它可能有助于澄清问题。

延伸阅读：http://meta.wikimedia.org/wiki/404_handler_caching

【讨论】：

请注意，ErrorDocument 并不是你能做的最好的事情，因为它会在 apache 的错误日志中生成条目，使用 -f 重定向会更好。
感谢您的意见。您是说无论 php 脚本有多好，它都会减慢服务器速度，或者正如您在帖子中所说的那样“无论如何它都会杀死您的服务器。”
无论脚本有多好，它都会减慢服务器的速度。对于每个图像，服务器都必须加载 php 并让它逐字节传输图像。让 apache 完成这项工作，甚至不经过 php 解释器。因此，许多其他可能的错误将被自动避免，例如会话、内容长度、缓存、mime/type 等。当性能至关重要时，您甚至不应该加载 php（但在生成时）。
投反对票的人，你能解释一下原因吗？

【解决方案18】：

由于某些浏览器每个域仅下载 2 个并行下载，您能否通过两到三个不同的主机名向 shard the requests 添加其他域。例如1.imagecdn.com 2.imagecdn.com

【讨论】：

+1 为您的建议：谢谢，但如果您仔细查看我的（承认：非常混乱的图纸），您会发现有些项目来自.......有些来自........com ..........de 但是，也许这并没有你的建议那么有效？（我看到您建议使用子域，而不仅仅是不同的域。）

【解决方案19】：

大部分缓慢的问题是您的 TTFB（到第一个字节的时间）太高。如果不熟悉您的服务器配置文件、代码和底层硬件，这是一个很难解决的问题，但我可以看到它在每个请求中都很猖獗。你有太多的绿色条（坏）和很少的蓝色条（好）。您可能想要停止优化前端，因为我相信您在该领域已经做了很多。尽管有“80%-90% of the end-user response time is spent on the frontend”这句格言，但我相信你的事情发生在后端。

TTFB 是后端的东西，服务器的东西，输出和握手之前的预处理。

为您的代码执行计时以查找慢速数据库查询等慢速内容、为查找慢速函数而输入和退出函数/方法的时间。如果您使用 php，请尝试Firephp。有时它是在启动或初始化期间运行一两个慢查询，例如提取会话信息或检查身份验证等等。优化查询可以带来一些好的性能增益。有时代码使用 php prepend 或 spl autoload 运行，因此它们可以在所有内容上运行。其他时候，它可能是错误配置的 apache conf 和调整以节省时间。

寻找低效的循环。查找因磁盘驱动器故障或磁盘空间使用率高而导致的缓存调用缓慢或 I/O 操作缓慢。查找内存使用情况以及正在使用的内容和位置。仅使用来自世界各地不同位置而不是同一位置的第一次视图，对单个图像或文件运行 10 次运行的网页测试重复测试。并阅读您的访问和错误日志，太多的开发人员忽略它们，只依赖输出的屏幕错误。如果您的虚拟主机有支持，请向他们寻求帮助，如果他们不礼貌地向他们寻求帮助，那也不会受到伤害。

您可以尝试使用 DNS 预取来对抗众多域和资源，http://html5boilerplate.com/docs/DNS-Prefetching/

您自己的服务器是好/不错的服务器吗？有时更好的服务器可以解决很多问题。我是“hardware is cheap, programmers are expensive”心态的粉丝，如果你有机会和钱升级服务器。和/或使用像maxcdn 或cloudflare 或类似的CDN。

祝你好运！

（p.s. 我不为这些公司工作。另外，上面的 cloudflare 链接会认为 TTFB 并不重要，我把它放在那里，这样你就可以再拿一次了。）

【讨论】：

亲爱的 Anthony，非常感谢您提供这些富有洞察力的“背景”知识。我同意有时硬件是瓶颈，尤其是当托管公司在共享托管环境中托管服务器部分时，这一点不太明显。我认为 cloudflare 是结合 apache 配置优化尝试的不错选择。问候！