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

哇，很难用这个图像来解释事情. . 但是这里，有些尝试:

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

只是一个简单的猜测，因为这种分析需要大量的 A/B 测试: 您的。Ch 域似乎很难到达(在第一个字节到达之前有很长的绿色带)。

这意味着。网站托管不善或你的 ISP 没有一个很好的路线到他们。

根据这些图表，这可以解释性能的巨大损失。

值得注意的是，有一个很酷的工具 巨大无比，它可以帮助您根据资源加载的顺序排序。

尝试在您的站点/页面上运行 Y! Slow 和 Page Speed 测试，并遵循指导方针来解决可能的性能瓶颈。一旦你在 Y 中得到更高的分数，你将获得巨大的性能提升。

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

首先，使用这些多域需要多次 DNS 查找。您最好使用 把许多图像合成一个精灵而不是传播请求。

其次，当我加载页面时，我看到 all.js 上的大部分阻塞(~ 1.25 s)。我看到这是从(旧版本的) jQuery 开始的。您应该从 Google CDN 中引用它，不仅仅是 减少载入时间，而是整个 可能会避免对它的 HTTP 请求。

具体来说，可以在这些 URL 上引用最新的 jQuery 和 jQuery UI 库(如果您对我为什么省略 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

如果使用的是默认的 jQueryUI 主题之一，也可以使用 把它的 CSS 和图片从 Google CDN 上撤下来。

对 jQuery 宿主进行了优化之后，还应该将 awmlib2.js和 tooltiplib.js组合成一个文件。

如果您解决了这些问题，您应该会看到一个显著的改进。

几天前我也遇到过类似的问题，我发现了 头 J。 这是一个 Javascript 插件，它允许你并行加载所有的 JS 文件。 希望能帮上忙。

所以你的 PHP 脚本正在生成每个页面加载的缩略图？首先，如果被缩略图显示的图像没有那么频繁地变化，那么您能否设置一个缓存，以便在每次加载页面时不必解析它们？其次，您的 PHP 脚本是否使用类似 imagecopyresampled()的东西来创建缩略图？这是一个非常重要的下行示例，PHP 脚本在完成收缩之前不会返回任何内容。使用 imagecopymerged()代替将降低图像的质量，但加速的过程。你减少了多少？这些缩略图是原始图像的5% 还是50% ？较大的原始图像可能会导致速度减慢，因为 PHP 脚本在缩小原始图像并输出较小的缩略图之前，必须在内存中获得原始图像。

我远不是专家，但是..。

关于这一点: ”条件请求返回未改变的完整内容 还有我的评论。

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

1. 是否有一个缓存版本的缩略图。
2. 缓存的版本是否比原始图像新。

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

1. 是否有 HTTP _ IF _ MODIFIED _ SINCE 头文件
2. 缓存版本的最后修改时间与 HTTP _ IF _ MODIFIED _ SINCE 相同

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

如果这两个都是真的，那么应该返回一个304 http 状态。我不知道是否需要，但我也亲自返回缓存控制，过期和最后修改的标题连同304。

关于 GZip，我被告知没有必要使用 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 所说。该错误指出: “当我询问服务器自上次以来是否修改了该映像时，它会发送整个映像，而不是简单的是/否”。

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

1. - 你有没有考虑过侧写?-可能会有些问题。
2. 结合上述问题，您的脚本运行的次数可能比需要的次数多得多。理想情况下，它应该生成大拇指 除非的原始图像被修改，并发送缓存大拇指为每个其他请求。您是否检查过脚本是否在不必要地生成图像(例如，对于每个请求) ？

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

除此之外，您还可以应用 如何正确地做网站上这个漂亮的 SO 问题的性能部分中的一些明智的优化思想，比如将资源划分为无 cookie 的子域等等。但是无论如何，一个3k 图像不应该花费一秒钟来加载，这是显而易见的，当比较图表中的其他项目。在进行优化之前，您应该尝试发现问题。

调查 PHP 对会话数据的使用情况。也许(仅仅是也许) ，图像生成 PHP 脚本正在等待获得会话数据的锁，该数据被仍然呈现的主页或其他图像呈现脚本锁定。这将使所有的 JavaScript/浏览器优化几乎无关紧要，因为浏览器正在等待服务器。

PHP 为每个运行的脚本锁定会话数据，从会话处理开始，到脚本结束，或者调用 session _ write _ close ()。这有效地序列化了事物。查看关于会话的 PHP 页面，特别是注释，比如 这个。

您是否尝试过在 NGINX 网络服务器下建立几个子域，专门用于服务图像和样式表等静态数据？一些有用的东西可能已经找到了 在这个话题中。

我已经找到了您的网站的网址，并检查了个人的 jpg 文件从主页。 虽然现在加载时间是合理的(161毫秒) ，但等待126毫秒，这是太多了。

您最后修改的头部都设置为 Sat，01 Jan 201112:00:00 GMT，这看起来太“圆”，不是真正的生成日期; -)

由于 Cache-control 是“ public，max-age = 14515200”，任意最后修改的头在168天后可能会导致问题。

不管怎样，这不是延误的真正原因。

当缩略图已经存在时，您必须检查缩略图生成器执行什么操作，以及什么操作会占用如此多的时间来检查和传递图片。

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

也许整个事情使用一个框架或连接到一些数据库免费。我在一些服务器上看到过非常慢的 mysql _ connect () ，主要是因为它们使用 TCP 而不是套接字进行连接，有时还有一些 DNS 问题。

我知道你不能把你的付费发电机寄到这里但恐怕有太多可能的问题..。

如果没有很好的理由(通常没有) ，那么您的映像就不应该调用 PHP 解释器。

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

如果它不工作，至少你现在将它没有任何关系的方式，图像创建和检查。

您是否尝试过将 PHP 生成的缩略图替换为常规图像，以查看是否有任何区别？ 问题可能就在附近 - php 代码中的 bug 导致每次服务器调用时缩略图的再生 - 与时钟问题相关的代码延迟(sleep () ?) 一个硬盘问题导致一个非常糟糕的比赛条件，因为所有的缩略图被加载/生成在同一时间。

关于延迟的缩略图，尝试在缩略图生成脚本中最后一次调用 Header ()之后立即调用 冲水。完成之后，重新生成瀑布图，看看延迟现在是否在主体上而不是标题上。如果是这样，那么您需要仔细研究生成和/或输出图像数据的逻辑。

处理缩略图的脚本应该使用某种类型的缓存，这样它对您提供的图像所采取的任何操作只会在绝对必要的时候才会发生。看起来每次提供缩略图时都会发生一些昂贵的操作，这会延迟脚本中的 任何输出(包括头部)。

我认为，与其使用 缩略图生成器脚本缩略图生成器脚本，你必须给 TinySRC一个快速快速和云托管缩略图生成的尝试。 它有一个非常简单和易于使用的 API，你可以像这样使用:-

Http://i.tinysrc.mobi/ http://domain.tld/path_to_img.jpg

您可以检查 API 摘要 给你

常见问题

TinySrc 花了我多少钱？

没什么。

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

现在。

服务可靠吗？

我们不能保证 tinySrc 服务。然而，它运行在一个 abc0上，因此它提供全球高可用性。它应该足以满足你所有的需要。

它有多快？

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

祝你好运，这只是个建议，因为你没有给我们展示密码

这只是一个大胆的猜测，因为我还没有看过你的代码，但我怀疑会话可能在这里发挥了作用，以下是来自 session_write_close()的 PHP 手册条目:

会话数据通常存储在 你的脚本终止了 需要调用 session _ write _ close () , 但是当会话数据被锁定到 防止并发写入只有一个 脚本可以在任何 当一起使用框架集时 你会体验到 由于这个原因，帧一个接一个地加载 锁定。 你可以减少时间 需要加载所有的帧 尽快结束会议 会话变量的更改如下 完成