Узнайте, где ваш PHP-код замедляется (проблема с производительностью)
https://stackoverflow.com/questions/55720
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Вот мой первый вопрос в SO.
У меня есть внутреннее приложение для моей компании, которое меня недавно попросили поддерживать.Приложения построены на PHP и довольно хорошо закодированы (OO, DB Abstraction, Smarty), ничего лишнего.
Проблема в том, что приложения очень медленно.
Как мне узнать, что замедляет работу приложения?Я оптимизировал код так, чтобы он делал очень мало запросов к базе данных, поэтому я знаю, что выполнение PHP-кода занимает некоторое время.Мне нужно получить инструменты, которые могут мне в этом помочь, и разработать стратегию проверки моего кода.
Я могу сам выполнять проверку/стратегию, но мне нужно больше инструментов PHP, чтобы выяснить, где мое приложение не работает.
Мысли?
Решение
я использовал XDebug профилирование недавно в похожей ситуации.Он выводит полный отчет о профиле, который можно прочитать во многих распространенных приложениях для профилирования (хотя я не могу дать вам список, я просто использовал то, которое поставляется со Slackware).
Другие советы
Как упомянул Хуан, xDebug превосходен.Если вы используете Windows, WinCacheGrind позволит вам просматривать отчеты.
Посмотрите презентацию Расмуса Лердорфа (создателя PHP).Он приводит несколько хороших примеров тестирования скорости PHP и того, на что следует обратить внимание, а также некоторые внутренние особенности, которые могут замедлить работу.XDebug — один из инструментов, который он использует.Он также делает очень убедительное замечание о том, каковы затраты на производительность при использовании фреймворков.
Видео:http://www.archive.org/details/simple_is_hard
Слайды (так как на видео плохо видно):http://talks.php.net/show/drupal08/1
Существует множество переменных, которые могут повлиять на производительность вашего приложения.Я рекомендую вам не сразу предполагать, что проблема в PHP.
Во-первых, как вы обслуживаете PHP?Пробовали ли вы базовую оптимизацию самого Apache или IIS?Занят ли сервер обработкой других типов запросов?Воспользовались ли вы Ускоритель PHP-кода?Один из способов проверить, является ли сервер вашим узким местом, — попробовать запустить приложение на другом сервере.
Во-вторых, снижается ли производительность всего приложения или это влияет только на определенные страницы?Это может дать вам представление о том, с чего начать анализ производительности.Если все приложение работает медленно, проблема, скорее всего, связана с базовым сервером/платформой или с глобальным SQL-запросом, который является частью каждого запроса (например, аутентификация пользователя).
В-третьих, вы упомянули о минимизации количества SQL-запросов, а как насчет оптимизации существующих запросов?Если вы используете MySQL, используете ли вы преимущества каждой системы хранения данных?Ты бежал? ОБЪЯСНЯТЬ по самым важным запросам, чтобы убедиться, что они правильно проиндексированы?Это критически важно для запросов, обращающихся к большим таблицам;чем больше набор данных, тем больше вы заметите последствия плохой индексации.К счастью, статей много. такой как этот которые объясняют, как использовать EXPLAIN.
В-четвертых, распространенной ошибкой является предположение, что ваш сервер базы данных будет автоматически использовать все ресурсы, доступные системе.Вам следует убедиться, что вы явно выделили достаточные ресурсы для вашего приложения базы данных.Например, в MySQL вам понадобится добавить пользовательские настройки (в файл my.cnf) для таких вещей, как буфер ключей, размер временной таблицы, параллелизм потоков, размер пула буферов innodb и т. д.
Если вы дважды проверили все вышеперечисленное и все еще не можете найти узкое место, профилировщик кода, такой как Xdebug, определенно может помочь.Лично я предпочитаю профилировщик Zend Studio, но, возможно, это не лучший вариант, если вы уже не используете преимущества остальной части стека платформы Zend.Однако, по моему опыту, очень редко сам PHP является основной причиной низкой производительности.Зачастую профилировщик кода может помочь более точно определить, какие именно запросы к БД виноваты.
phpED (http://www.nusphere.com/products/phped.htm) также предлагает отличные возможности отладки и профилирования, а также возможность добавлять часы, точки останова и т. д. в код PHP.Встроенный профилировщик напрямую предлагает временную разбивку каждого вызова функции и метода класса из среды IDE.Плагины для браузера также обеспечивают быструю интеграцию с Firefox или IE (т.посетите медленный URL-адрес в браузере, затем нажмите кнопку для профилирования или отладки).
Было очень полезно указать, где приложение работает медленно, чтобы сосредоточить большую часть усилий по кодированию;и это позволяет избежать траты времени на оптимизацию и без того быстрого кода.Попробовав Zend и Eclipse, я убедился в простоте использования phpED.
Имейте в виду, что и Xdebug, и phpED (с DBG) потребуют установки дополнительного модуля PHP при отладке на веб-сервере.phpED также предлагает (не опробованную мной) возможность локальной отладки.
Профиль Xdebug определенно подойдет.Еще один совет — WincacheGrind хорош, но в последнее время не обновлялся. http://code.google.com/p/webgrind/ - в браузере может быть простая и быстрая альтернатива.
Однако есть вероятность, что это все равно база данных.Проверьте наличие соответствующих индексов и наличие достаточного объема памяти для кэширования как можно большего количества рабочих данных.
Также вы можете использовать АПД (Расширенный PHP-отладчик).
Заставить это работать довольно легко.
$ php apd-test.php
$ pprofp -l pprof.SOME_PID
Trace for /Users/martin/develop/php/apd-test/apd-test.php
Total Elapsed Time = 0.12
Total System Time = 0.01
Total User Time = 0.07
Real User System secs/ cumm
%Time (excl/cumm) (excl/cumm) (excl/cumm) Calls call s/call Memory Usage Name
--------------------------------------------------------------------------------------
71.3 0.06 0.06 0.05 0.05 0.01 0.01 10000 0.0000 0.0000 0 in_array
27.3 0.02 0.09 0.02 0.07 0.00 0.01 10000 0.0000 0.0000 0 my_test_function
1.5 0.03 0.03 0.00 0.00 0.00 0.00 1 0.0000 0.0000 0 apd_set_pprof_trace
0.0 0.00 0.12 0.00 0.07 0.00 0.01 1 0.0000 0.0000 0 main
Существует хороший учебник, как скомпилировать APD и выполнить с его помощью профилирование: http://martinsikora.com/compiling-apd-for-php-54
Если это большая база кода, попробуйте APC, если вы еще этого не сделали.
вы также можете попробовать использовать функцию Register_tick_function в php.который сообщает php периодически вызывать определенную функцию в вашем коде.Затем вы можете отслеживать, какая функция выполняется в данный момент, и количество времени между вызовами.тогда вы сможете увидеть, что занимает больше всего времени.http://www.php.net/register_tick_function
Мы используем среду разработки Zend (Windows).Вчера мы устранили скачок использования памяти, пройдя через отладчик при запуске Process Explorer, чтобы наблюдать за активностью памяти/процессора/диска при выполнении каждой строки.
Обозреватель процессов: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx.
ZDE включает в себя базовый профилировщик производительности, который может показывать время, затраченное на каждый вызов функции во время запросов страниц.
Я использую комбинацию Тест PEAR и log4php.
В верхней части сценариев, которые я хочу профилировать, я создаю объект, который окружает Бенчмарк_таймер объект.По всему коду я добавляю $object->setMarker("name");звонки, особенно по поводу подозрительного кода.
Класс-оболочка имеет метод уничтожения, который принимает информацию журнала и записывает ее в log4php.Обычно я отправляю это в системный журнал (многие серверы, объединяются в один файл журнала на одном сервере).
Во время отладки я могу просматривать файлы журналов и видеть, где мне нужно что-то улучшить.Позже в рабочей среде я смогу проанализировать файлы журналов и провести анализ производительности.
Это не xdebug, но он всегда включен и дает мне возможность сравнить любые два выполнения кода.
Вы также можете посмотреть Высокая доступность прокси или любое другое решение для балансировки нагрузки, если причиной медленной обработки приложения является снижение производительности вашего сервера.сервер.
