CakePHP 输出缓慢,但查询似乎达到标准

发布于 2024-11-06 02:33:33 字数 740 浏览 2 评论 0原文

我要说的大部分结果是显而易见的,但我正在寻找核心中可能提供的任何其他配置选项或建议,或者我可以对脚本进行的其他修改:

  1. 我切换了我的 CakePHP 应用程序从开发服务器切换到生产服务器。

  2. 我正在测试的查询在新服务器上需要两倍的时间来处理(大约 10-12 秒)。对于这个测试,我实际上是在计算屏幕结果加载时间。因此,从按下提交按钮的那一刻起,到实际的视觉输出结果完成。

  3. 我的 CakePHP 调试的查询输出是(相同的精确查询):

-- 开发:132 个查询花费了 5 毫秒 -- 生产:132 个查询花费了 53 毫秒。

很明显,查询的运行速度有很大不同,但即使较慢的结果也不到一秒!

看起来速度变慢是网络或处理器的问题,但我在使用 CakePHP 进行 MySQL 基准测试方面经验不足,无法知道这是控制器负载问题还是实际的 MySQL 问题。较慢的结果为 53 毫秒这一事实并不让我相信我的 MySQL 查询很慢,它似乎在实际输出中发生减慢的地方。

以下是完整 MySQL 查询调试转储的链接: http://notepub.com/#fb=&note=185197

我'我尝试删除查询的部分,更改我的连接方法,并且我还使用 containsable 作为输出结果。我将继续测试..感谢您的任何反馈或想法。

Most of the outcome of what I am about to say is obvious, but I am looking for any additional configuration options or suggestions that might be available in the core or other modifications I can make to the script:

  1. I switched my CakePHP app from development to production servers.

  2. The queries I am testing take 2x time to process on the new server (about 10-12 seconds). For this test, I am actually counting the screen result load time. So from the second the submit button is pressed to the actual visual output results are completed.

  3. My query output by CakePHP debug is (same exact query):

-- Development: 132 queries took 5 ms
-- Production: 132 queries took 53 ms.

It's clear that the queries are running much different in speed, but even the slower result is under a second!

It appears the slow down is the network or processor, but I am not seasoned enough in MySQL benchmarks w/ CakePHP to know if this is a Controller load issue or an actual MySQL issue. The fact that the results in the slower are 53ms does not lead me to believe my MySQL query is slow, it appears its somewhere in the actual output where the slowdown is happening..

Here is a link to a full MySQL query debug dump:
http://notepub.com/#fb=¬e=185197

I've tried removing sections of the query, changing my join methods, and I am also using containable for the output results. I am going to continue testing.. Thanks for any feedback or ideas.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

ゞ记忆︶ㄣ 2024-11-13 02:33:33

这个答案更多的是猜测而不是答案,但无论如何它可能对您有帮助:

查看您的日志,实际上只有一个查询需要花费时间,并且它:

SELECT `Zip`.`id`, `Zip`.`title`, `PlansZip`.`id`, `PlansZip`.`plan_id`, `PlansZip`.`zip_id` FROM `zips` AS `Zip` JOIN `plans_zips` AS `PlansZip` ON (`PlansZip`.`plan_id` IN (253, 774, 137, 505, 114, 260, 501, 841, 268, 239, 497, 762, 768, 246, 123, 750, 756, 130, 886, 836, 839, 315, 331, 299) AND `PlansZip`.`zip_id` = `Zip`.`id`) ORDER BY `Zip`.`title` ASC

我认为花费这么长时间的原因是您加入这些查询的方式两张桌子。我想您会发现这样的方法会快得多:

SELECT `Zip`.`id`, `Zip`.`title`, `PlansZip`.`id`, `PlansZip`.`plan_id`, `PlansZip`.`zip_id` FROM `zips` AS `Zip` JOIN `plans_zips` AS `PlansZip` ON `PlansZip`.`zip_id` = `Zip`.`id`
WHERE `PlansZip`.`plan_id` IN (253, 774, 137, 505, 114, 260, 501, 841, 268, 239, 497, 762, 768, 246, 123, 750, 756, 130, 886, 836, 839, 315, 331, 299) ORDER BY `Zip`.`title` ASC

我在自己的数据库中做了一个类似的查询,发现使用第二种方法将运行查询所需的时间减少了一个相当重要的因素。

我提出的另一个问题是您的开发系统是否是生产系统的镜像。如果您的产品系统中有大量记录,您可能会看到缓慢的查询无法扩展。返回的记录数量与生产记录数量有什么区别?即使 SQL 不是问题所在,它也可能会因为必须传输大量数据甚至将其呈现在屏幕上而出现滞后。

This answer is speculation more than an answer, but it might help you anyways:

Looking at your log, there's really only one query that's taking any time, and its:

SELECT `Zip`.`id`, `Zip`.`title`, `PlansZip`.`id`, `PlansZip`.`plan_id`, `PlansZip`.`zip_id` FROM `zips` AS `Zip` JOIN `plans_zips` AS `PlansZip` ON (`PlansZip`.`plan_id` IN (253, 774, 137, 505, 114, 260, 501, 841, 268, 239, 497, 762, 768, 246, 123, 750, 756, 130, 886, 836, 839, 315, 331, 299) AND `PlansZip`.`zip_id` = `Zip`.`id`) ORDER BY `Zip`.`title` ASC

I think the reason it's taking so long is the way you're joining those two tables. I think you'll find something like this would be much faster:

SELECT `Zip`.`id`, `Zip`.`title`, `PlansZip`.`id`, `PlansZip`.`plan_id`, `PlansZip`.`zip_id` FROM `zips` AS `Zip` JOIN `plans_zips` AS `PlansZip` ON `PlansZip`.`zip_id` = `Zip`.`id`
WHERE `PlansZip`.`plan_id` IN (253, 774, 137, 505, 114, 260, 501, 841, 268, 239, 497, 762, 768, 246, 123, 750, 756, 130, 886, 836, 839, 315, 331, 299) ORDER BY `Zip`.`title` ASC

I did a comparable query in my own database, and found using the second method reduced the time required to run the query by a pretty significant factor.

The other question I'd put forward is whether or not your dev system is a mirror of the production system. If there's a ton more records in your prod system, you could just be seeing slow queries failing to scale up. What's the difference between the number of records returning on vs production? Even if SQL isn't the problem, it could be lagging from having to transmit a large amount of data or even rendering it on the screen.

听不够的曲调 2024-11-13 02:33:33

我认为我遇到的部分问题是我的查询是以 CakePHP 风格完成的,我正在研究如何翻译你所拥有的内容。

这是我的原创:

array(
        'joins'      => array(
            array(
                'table'      => 'plans_zips',
                'alias'      => 'PZips',
                'type'       => 'inner',
                'foreignKey' => false,
                'conditions' => array('Plan.id = PZips.plan_id')
            ),
            array(
                'table'      => 'zips',
                'alias'      => 'Zips',
                'type'       => 'inner',
                'foreignKey' => false,
                'conditions' => array('Zips.id = PZips.zip_id')
            ),   
        ),

I think part of the problem I am running into is my query is done CakePHP style, and I am working out how to translate what you have.

This is my original:

array(
        'joins'      => array(
            array(
                'table'      => 'plans_zips',
                'alias'      => 'PZips',
                'type'       => 'inner',
                'foreignKey' => false,
                'conditions' => array('Plan.id = PZips.plan_id')
            ),
            array(
                'table'      => 'zips',
                'alias'      => 'Zips',
                'type'       => 'inner',
                'foreignKey' => false,
                'conditions' => array('Zips.id = PZips.zip_id')
            ),   
        ),
古镇旧梦 2024-11-13 02:33:33
  1. 查询 129 检索 10563 行,如此数量的行自然会导致一些(网络?)流量
  2. 如果您想加快查询速度,可以尝试向以下字段添加索引:
    PlansZip.plan_id
    PlansZip.zip_id
  3. 按照 user470714 的建议重构您的查询
  1. Query 129 retrieves 10563 rows, it is natural to cause some (network?) traffic for such an amount of rows
  2. If you want to speed up your queries you can try adding indexes to the following fields:
    PlansZip.plan_id
    PlansZip.zip_id
  3. Restructure your query as user470714 suggested
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文