分析建议 - 尝试查明网站加载问题
我接管了一个 WordPress 电子商务网站（尽管这个问题更多的是关于一般分析），该网站存在性能问题，似乎只影响 CMS 管理部分的一个特定区域。当尝试编辑一种附加有大量属性的特定类型产品时，该页面在 99% 的情况下会导致浏览器崩溃。我预计这将归因于 MySQL 查询导致瓶颈，但是当我分析数据库时，我得到以下结果：
Total Queries: 174 - Total Time Of MySQL Queries: 0.11370
这表明瓶颈发生在其他地方，但我不确定它可能在哪里。如果我在页面上运行 YSlow，虽然加载了大约 20 个脚本和样式表，但没有什么重大的东西可以解释该问题，因此可以在那里进行一些优化。我将启用一个操作码缓存库，这将提高 PHP 性能，但是我还能做些什么来尝试识别这里的问题吗？谢谢。
I've taken over a wordpress e-comm (although this question is more about profiling generally) site which has a performance issue which seemingly only affects one specific area in the admin section of the CMS. When trying to edit one particular type of product, which has a large number of attributes attached to it, the page effectively causes the browser to crash 99% of the time. I expected this to be down to MySQL queries causing the bottleneck, however when I profiled the db, I got the following results:
Total Queries: 174 - Total Time Of MySQL Queries: 0.11370
This suggests the bottleneck is happening elsewhere, but I'm not sure where it could be. If I run YSlow on the page, there is nothing drastic there which would explain the issue, although there are around 20 scripts and stylesheets loaded, so some optimisation could be done there. I'm going to enable an opcode cache library which will improve PHP performance, but is there anything else I can do to try to identify the issue here? Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
使用像 Xdebug 这样的分析器...如果问题不是在数据库中，我是 PHP 有问题...找出代码的哪一部分花费了更长的时间...Xdebug 会告诉您每个函数调用所花费的时间以及内存使用情况。
Use a Profiler like Xdebug...if the problem is not their in database my be PHP has the problem..find out which part of code is taking longer...Xdebug will tell you time taken per function call as well as memory usase.
上次我分析 WordPress 时，我花了十几次基于
microtime(1)的计算才发现加载时间只有 2.5 秒一半的地方。它正在加载和解析 .mo 本地化文件。安装 APC 缓存也获得了相当大的收益，因为事实证明，wordpress 是一个臃肿的怪物，需要花费大量时间来解析它的代码。
Last time I profiled wordpress, it took me a dozen
microtime(1)-based calculations to spot the place that took half of 2.5 seconds loading time. It was loading and parsing of .mo localization file.Also considerable gain was from installing APC cache, as it turned out that wordpress is a heavy bloated monster consumes a lot of time to parse it's codes.
我会
timecurl -b PHPSESSID=123 http://example.com/wp-admin/I would
time curl -b PHPSESSID=123 http://example.com/wp-admin/firebug（firefox 的附加组件）是我所知道的查找此类问题的最佳工具。您还可以安装另一个名为“页面速度”的插件。它会准确地显示哪一部分需要更长的加载时间。
另一种选择是使用“时间”打印来调试代码，看看哪个时间间隔最大：
http://php.net/manual/en/function.microtime.php
firebug (add-on to firefox) is the best tool that I know to locate such issues. You can also install another pluging called "page speed". it will show you exactly which part takes longer to load.
another option is to debug your code with "time" printing and see which has the biggest time-gap:
http://php.net/manual/en/function.microtime.php