CakePHP медленный вывод, но запрос, кажется, соответствует - PullRequest
Новая
       3

CakePHP медленный вывод, но запрос, кажется, соответствует

0 голосов
/ 10 мая 2011

Большая часть результатов того, что я собираюсь сказать, очевидна, но я ищу любые дополнительные параметры конфигурации или предложения, которые могут быть доступны в ядре, или другие модификации, которые я могу внести в сценарий:

  1. Я переключил свое приложение CakePHP с разработки на рабочие серверы.

  2. Запросы, которые я тестирую, обрабатываются на новом сервере 2 раза (около 10-12 секунд)).Для этого теста я на самом деле рассчитываю время загрузки результата экрана.Таким образом, со второго нажатия кнопки отправки до фактического результата визуального вывода завершены.

  3. Мой запрос вывода в результате отладки CakePHP (тот же точный запрос):

- Разработка: 132 запроса заняли 5 мс - Производство: 132 запроса заняли 53 мс.

Ясно, что запросы выполняются по-разному по скорости, но даже более медленный результат находится подсекунда!

Похоже, замедление - это сеть или процессор, но я недостаточно опытен в тестах MySQL с CakePHP, чтобы понять, является ли это проблемой загрузки контроллера или реальной проблемой MySQL.Тот факт, что результаты медленнее 53 мс, не дает мне повода полагать, что мой запрос MySQL медленный, он появляется где-то в реальном выводе, где происходит замедление ..

Вот ссылка на полныйОтладочный дамп запроса MySQL: http://notepub.com/#fb=&note=185197

Я попытался удалить разделы запроса, изменить методы соединения, а также я использую в качестве выводимых результатов.Я собираюсь продолжить тестирование. Спасибо за любые отзывы или идеи.

Ответы [ 3 ]

0 голосов
/ 11 мая 2011

Я думаю, что часть проблемы, с которой я сталкиваюсь, заключается в том, что мой запрос выполнен в стиле 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')
            ),   
        ),
0 голосов
/ 12 мая 2011
  1. Запрос 129 извлекает 10563 строки, поэтому для такого количества строк естественно вызвать некоторый (сетевой?) Трафик
  2. Если вы хотите ускорить свои запросы, попробуйте добавить индексыследующие поля: PlanZip.plan_id Планы Zip.zip_id
  3. Перестройте ваш запрос, как предложил пользователь470714
0 голосов
/ 10 мая 2011

Этот ответ - предположение, а не ответ, но в любом случае он может вам помочь:

Глядя на ваш журнал, на самом деле есть только один запрос, который занимает какое-то время, и он: 

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 не является проблемой, он может отстать от необходимости передавать большой объем данных или даже отображать их на экране.

...