Совет по профилированию - попытка точно определить проблему загрузки сайта - PullRequest
8 голосов
/ 29 января 2012

Я завладел сайтом WordPress e-Comm (хотя этот вопрос больше касается профилирования в целом) сайта, который имеет проблему с производительностью, которая, по-видимому, затрагивает только одну конкретную область в разделе администратора CMS. При попытке отредактировать один конкретный тип продукта, к которому прикреплено большое количество атрибутов, страница приводит к сбою браузера в 99% случаев. Я ожидал, что это будет связано с запросами MySQL, вызывающими узкое место, однако, когда я профилировал базу данных, я получил следующие результаты:

Всего запросов: 174 - Общее время запросов MySQL: 0.11370

Это говорит о том, что узкое место происходит в другом месте, но я не уверен, где это может быть. Если я запустил YSlow на странице, то там нет ничего радикального, что могло бы объяснить проблему, хотя загружено около 20 сценариев и таблиц стилей, поэтому можно провести некоторую оптимизацию. Я собираюсь включить библиотеку кэширования кода операции, которая улучшит производительность PHP, но есть ли что-то еще, что я могу сделать, чтобы попытаться определить проблему здесь? Спасибо.

Ответы [ 4 ]

1 голос
/ 14 марта 2012

Я хотел бы

  • Использовать Firebug или панель Chrome Net, чтобы увидеть, является ли страница или JavaScript / CSS / imges причиной замедления (интерфейс)
  • Используйте curl , чтобы узнать, сколько времени занимает страница: time curl -b PHPSESSID=123 http://example.com/wp-admin/
  • Включить / установить Xdebug и включить профилирование.Используйте KCachegrind , чтобы увидеть, какие функции вызывают самые большие задержки.
1 голос
/ 14 февраля 2012

Используйте профилировщик, такой как Xdebug ... если проблема не в их базе данных, у меня будет проблема с PHP ... выясните, какая часть кода занимает больше времени ... Xdebug также сообщит вам время, затраченное на вызов функциикак память использовать.

1 голос
/ 14 февраля 2012

В прошлый раз, когда я профилировал WordPress, мне потребовалось дюжина вычислений на основе microtime(1), чтобы определить место, которое заняло половину 2,5 секунды времени загрузки.Это была загрузка и разбор файла локализации .mo.

Также значительный выигрыш был получен от установки кэша APC, поскольку выяснилось, что WordPress - это сильно раздутый монстр, требующий много времени для анализа своих кодов.

1 голос
/ 31 января 2012

firebug (дополнение к firefox) - лучший из известных мне инструментов для обнаружения таких проблем. Вы также можете установить другой плагин под названием " скорость страницы ". он покажет вам, какая именно часть загружается дольше. другой вариант - отладить ваш код с помощью «временной» печати и посмотреть, какой из них имеет самый большой промежуток времени: http://php.net/manual/en/function.microtime.php

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...