Обеспечение предсказуемости профилирования производительности PHP

Question

Я использую xdebug с PHP для профилирования производительности.Но когда я запускаю один и тот же скрипт более одного раза, у меня часто бывают очень разные времена.Поэтому трудно понять, насколько можно доверять результатам.

Очевидно, что на машине происходит много событий, которые могут повлиять на производительность PHP.Но есть ли что-нибудь, что я могу сделать, чтобы уменьшить количество переменных, чтобы несколько тестов были более согласованными?

Я использую PHP под Apache, в Mac OS X.

Answer 1

1. Максимально уменьшите количество не связанных сервисов на коробке.
2. Сократите количество процессов Apache.
3. Заполните различные кэши, загрузив ваш скрипт aнесколько раз.Возможно, используйте инструмент тестирования производительности, такой как Apache ab или siege, чтобы убедиться, что все дочерние элементы Apache поражены.
4. Профилируйте ваш скрипт из командной строки, используя curl или wget так что Apache обслуживает только один ресурс: сам скрипт.

Может быть аргумент для получения большего числа «реального мира», пропуская некоторые из этих шагов.Я с нетерпением жду других ответов на этот вопрос.

Answer 2

Есть две разные задачи: измерение производительности и поиск проблем.

Для измерения времени, которое вам нужно, вы должны ожидать изменчивости, потому что это зависит от того, что еще происходит в машине. Это нормально.

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

Важно то, что вы находите действия, отвечающие за здоровые проценты, которые вы можете исправить, а затем исправить. Когда вы это сделаете, вы можете рассчитывать сэкономить время до этого процента, но вы должны сделать вывод. Измерение вторично.

Добавлено: Возможно, вы захотите спросить "Не нужно ли измерять, чтобы найти?" Рассмотрим пример. Предположим, вы запускаете свою программу с включенной отладкой, случайным образом приостанавливаете ее и видите в процессе закрытия файла журнала. Вы продолжаете это, а затем снова делаете паузу и видите то же самое. Ну, это грубое «измерение» говорит, что тратит на это 100% своего времени. Естественно, время, потраченное на это, на самом деле не 100%, но что бы это ни было, оно большое, и вы его нашли. Так что, возможно, вам не нужно открывать / закрывать файл так часто, или что-то в этом роде. Обычно требуется больше образцов, но не слишком много.

Answer 3

1. Как уже говорили другие, уменьшите количество работающих служб и программ до минимума
2. Выполните тест несколько раз подряд и в среднем учитывайте выбросы
3. Убедитесь, что кэширование любого типа отключено (если вы не хотите специально проверять его с помощью кэша)
4. Если результаты по-прежнему сильно различаются, проблема, скорее всего, связана с вашим профилирующим кодом. Это может иметь некоторые гоночные условия или зависит от сетевых подключений. Вы получите более подробную информацию, если предоставите код
5. Вы также можете столкнуться с некоторыми узкими местами на некоторых трассах. Если вы тщательно профилируете различные части сценариев, вы можете их поймать.