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

问题A部分 ▉（获得100个赏金，获得奖励）
主要问题是如何使此网站加载速度更快。首先，我们需要阅读这些瀑布。感谢所有关于瀑布读数分析的建议。从这里显示的各种瀑布图可以看出，主要瓶颈是：PHP生成的缩略图。David建议从CDN进行无协议的jquery加载，这虽然使我的网站总体速度提高了3％，却没有解决该网站的主要瓶颈，却使我受益匪浅。是时候澄清我的问题了，另一个奖励是：

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

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

[我网站上的一些背景信息：CSS位于顶部。底部的JS（Jquery，JQuery UI，购买的菜单awm / menu.js引擎，tabs 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

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

其次，当我加载您的页面时，我在all.js上看到了大部分阻塞（约1.25秒）。我看到这始于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

如果您使用默认的jQuery UI主题之一，则还可以将其CSS和图像从Google CDN中拉出。

随着托管jQuery的优化，你也应该结合起来awmlib2.js，并tooltiplib.js成一个单一的文件。

如果您解决了这些问题，您应该会看到重大的改进。

我有一个类似的问题，前几天和我发现head.js。这是一个Javascript插件，可让您并行加载所有JS文件。希望能有所帮助。

我距离专家还很远，但是...

关于此：“ If-Modified-Since条件请求返回的完整内容不变。” 和我的评论。

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

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

如果这些都不正确，则无论如何都应生成缩略图并返回。如果它们都为真，则应进行以下检查：

1. 是否有HTTP_IF_MODIFIED_SINCE标头
2. 缓存版本的最后修改时间与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

哇，很难用该图像来解释事物。.但是，这里有一些尝试：

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

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

这意味着.ch网站托管不佳，或者您的ISP没有通向他们的良好途径。

给定图表，这可以解释对性能的重大影响。

附带说明，有一个很酷的工具库，可以帮助您根据资源加载的顺序整理内容。

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

这些测试将告诉您什么地方出了问题以及要更改什么。

那么您的PHP脚本会在每次加载页面时生成缩略图吗？首先，如果正在缩略图化的图像不经常更改，您是否可以设置高速缓存以使每次加载页面时都不必解析它们？其次，您的PHP脚本是否使用类似imagecopyresampled()创建缩略图的方式？这是一个不平凡的缩减样本，PHP脚本在完成缩小工作之前不会返回任何内容。imagecopymerged()相反，使用会降低图像质量，但会加快处理速度。您正在减少多少呢？这些缩略图是原始图像的5％还是50％？由于PHP脚本必须先将原始图像保存在内存中，然后才能缩小并输出较小的缩略图，因此较大的原始图像可能会导致速度变慢。

我找到了您网站的网址，并从首页检查了一个单独的jpg文件。虽然加载时间现在很合理（161毫秒），但等待126毫秒，这实在太多了。

您最后修改的标头都设置为2011年1月1日星期六格林尼治标准时间，看起来太“圆”了，无法成为实际的生成日期；-)

由于Cache-Control是“ public，max-age = 14515200”，因此任何最后修改的标头都可能在168天后引起问题。

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

您必须检查缩略图已经存在时缩略图生成器的功能，以及可能花费大量时间检查和发送图片的缩略图生成器。

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

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

我了解您无法在此处发布付费生成器，但恐怕问题太多...

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

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

如果它至少不起作用，那么您现在将与创建和检查图像的方式无关。

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

从会话处理开始到脚本结束或调用session_write_close（），PHP都会锁定每个运行脚本的会话数据。这有效地序列化了事物。查阅有关会话的PHP页面，尤其是评论，例如this。

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

会话数据通常在脚本终止后存储，而无需调用session_write_close（），但是由于会话数据被锁定以防止并发写入，因此任何时候任何会话都只能对一个脚本进行操作。将框架集与会话一起使用时，由于此锁定，您将体验到框架逐一加载的情况。完成对会话变量的所有更改后，您可以通过结束会话来减少加载所有帧所需的时间。

就像我说的那样，我不知道您的代码在做什么，但是那些图似乎很可疑。编写多部分文件服务功能时，我遇到了类似的问题，并且遇到了同样的问题。提供大文件时，我无法使用多部分功能，也无法在下载完成之前打开另一个页面。打电话session_write_close()解决了我的两个问题。

您是否尝试过用常规图像替换php生成的缩略图以查看是否存在任何区别？问题可能出在附近-您的php代码中的错误导致每次服务器调用时都会重新生成缩略图-与时钟问题相关的代码延迟（sleep（）？）-导致严重竞争状况的hardrive问题因为所有缩略图都会同时加载/生成。

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

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

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

[height]（可选）：-如果还存在宽度，则这是一个以像素为单位的高度。它还会覆盖自适应大小或系列大小，并且可以以“-”或“ x”为前缀。

您可以在此处查看API摘要

常问问题

tinySrc花了我多少钱？

没有。

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

现在。

服务的可靠性如何？

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

有多快？

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

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

由于某些浏览器每个域仅下载2个并行下载，因此您是否不能添加其他域来将请求分片为2到3个不同的主机名。例如1.imagecdn.com 2.imagecdn.com

首先，您需要If-Modified-Since适当地处理请求，如James所说。该错误指出：“当我问您的服务器自上次修改该图像以来，它将发送整个图像，而不是简单的是/否。”

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

1. 您是否考虑过对其进行分析？它可能有一些问题。
2. 结合上述问题，您的脚本可能运行了比所需次数更多的时间。理想情况下，仅当原始图像被修改时，它才应生成缩略图，并为其他每个请求发送缓存的缩略图。您是否检查过脚本是否不必要地生成了图像（例如，针对每个请求）？

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

除此之外，您还可以应用这个总体不错的SO问题的性能部分中的一些聪明的优化思想，以如何正确地使用网站，例如将资源拆分为无cookie的子域等。但是无论如何，都是3k图像不需要花一秒钟的时间，与图表中的其他项目相比，这是显而易见的。您应该在优化之前尝试发现问题。

您是否尝试过在NGINX Web服务器下设置几个专门用于提供静态数据（如图像和样式表）的子域？在本主题中可能已经找到了有用的东西。

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

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

最慢的问题是您的TTFB（至第一个字节的时间）过高。在不熟悉服务器配置文件，代码和底层硬件的情况下，这是一个很难解决的问题，但是我可以看到它在每个请求中都很普遍。您有太多绿色条（坏）和很少有蓝色条（好）。您可能需要停止优化前端，因为我相信您在该领域已经做了很多工作。尽管有句谚语：“ 最终用户响应时间的80％-90％用于前端 ”，但我相信您正在后端使用。

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

定时执行代码以查找慢速的东西，例如慢速的数据库查询，输入和退出函数/方法的时间以查找慢速的函数。如果您使用php，请尝试使用Firephp。有时，是在启动或初始化期间运行一两个缓慢的查询，例如获取会话信息或检查身份验证等。优化查询可以提高性能。有时代码是使用php prepend或spl autoload运行的，因此它们可以在所有程序上运行。其他时间可能是由于配置不正确的apache conf和调整而节省了一天的时间。

寻找低效的循环。查找由于磁盘驱动器故障或磁盘空间使用过多而导致的高速缓存调用缓慢或I / O操作缓慢。查找内存使用情况以及正在使用的内容和位置。对来自单个图像或文件的10次运行进行一次webtest测试，该测试仅使用来自全球不同位置（而不是同一位置）的第一视图进行。并阅读您的访问和错误日​​志，太多的开发人员将其忽略，仅依赖输出的屏幕错误。如果您的虚拟主机有支持，请向他们寻求帮助，如果他们仍然不礼貌地向他们寻求帮助，那不会有任何伤害。

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

服务器是您自己的优质/体面的服务器吗？有时，更好的服务器可以解决很多问题。我喜欢“ 硬件便宜，程序员昂贵 ”的心态，如果您有机会和金钱来升级服务器。和/或使用CDN，例如maxcdn或cloudflare或类似名称。

祝好运！

（请注意，我在这些公司中都没有工作。同样，上面的cloudflare链接会指出TTFB并不那么重要，我把它扔在那里，这样您就可以得到另一份收益。）

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

您如何投放这些图片？如果通过PHP流式传输这些内容，那么即使它们已经生成，您所做的也很糟糕。

切勿使用PHP来流图像。无论使用哪种方式，它都会降低服务器的速度。

将它们放在具有有意义URI的可访问文件夹中。然后直接使用其真实URI对其进行调用。如果您需要即时生成，则应将.htaccess放在images目录中，该目录仅在缺少请求图像时才重定向到生成器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