У вас по какой-то причине очень долго выполняются скрипты - более 30 сек.
Исправить можно в принципе увеличив таймаут, но это неправильное решение. Разгадку надо искать в скриптах.
А тут вам, видимо, придётся разбераться самостоятельно.

Ну для этого придуман профайлинг - посмотрите в сторону xhprof, например.

"bsyomov" wrote:

посмотрите в сторону xhprof

можно использовать профайлинг xdebug - в phpstorm есть удобный инструмент для просмотра файлов профилирования
хотя конечно же у каждого додика своя методика

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

В разработке я тоже xdebug использую, т.к. это ещё и отладчик. И проблемы быстродействия не важны.

"bsyomov" wrote:

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

так а xdebug что на сервер не ставиться и потом просто файлы оттуда стягиваются и локально просматриваются или обязательно через вебморду просматривать отчеты при просмотре страниц?

Если расставить какие-нибудь знаки препинания, то возможно, вопрос и обретёт смысл. Но пока, я что-то понять его не могу. А может и с ними не смогу.
Может переформулировать доступнее?

"bsyomov" wrote:

то возможно, вопрос и обретёт смысл.

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

"bsyomov" wrote:

xdebug положет окончательно и так тормозящий сайт

так если включить только профилирование - запись файла профилировщика не положит твой сервер ну никак

и если кто то с вами не согласен - это не значит ,что он не прав , тем более я не услышал доводов весомых тому , что xhprof единственно возможное решение в качестве php профайлинга "на продакшене"
пока лишь понял , что у xdebugа якобы какие то проблемы с быстродействием и он ложет сайт
просто может не нужно в конфиге xdebug включать все подряд и тогда он не будет ложить сайты ?

ps только не надо переходить на личности - оставим все в рамках xdebug vs xhprof

"drupby" wrote:

или у тебя получилось его установить только локально? ну тогда поищи в интернетах - там полно статей по установке xdebug и его конфигурированию

Спасибо за совет, но я вполне умею пользоваться и xdebug и xhprof, и соответственно знаю, когда что лучше применять, поэтому и пытаюсь донести эту информацию.

"drupby" wrote:

и если кто то с вами не согласен - это не значит ,что он не прав

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

Как подключается xdebug: включается расширение, снимаются данные, расширение работает постоянно, добавляя внутри цикла исполнения свои коллбеки. Постоянно даёт нагрузку, и вполне измеримую, даже только на профайлере.
При этом, профилирование обычно производится тогда, когда уже есть проблемы с нагрузкой, и соответственно ситуация заметно усугубляется, и может перерасти в эффект "снежного кома", когда из-за небольшого увеличения нагрузки начинает быстро деградировать производительность...
Мы можем пользоваться тригером, но тогда не получим данных с пользовательских запросов. И xdebug даже при отключённом профайлинге даёт оверхед при выполнении скрипта, уже когда активно расширение.

Как подключается xhprof: включается расширение, в скрипте запускается профайлер. Вызывать можно с определённой вероятностью, что даёт статистически сколько-то срабатываний на определённое кол-во запросов. Таким образом, мы легко можем дозировано увеличив нагрузку, снять за некоторое продолжительное время нужные нам данные. Также, можно начать профилирование по любым другим условиям, которые можно придумать в рамках скрипта. Без вызова, оверхеда нет совсем, точнее чуть памяти на загрузку расширения, не более.
Собственно, он исторически и создавался для целей профилирования в продакшене, из за ограничений имевшихся инструментов, т.е. того самого xdebug.

"bsyomov" wrote:

из за ограничений имевшихся инструментов, т.е. того самого xdebug.

возможно я и не прав - конечно в "тяжелых случаях" xdebug и не прокатит , у меня не было просто случаев тестировать на ограниченных ресурсах , просто ведь в большинстве случаев если есть проблемы с производительностью приложения, ресурсы сервера все же позволяют воспользоваться как тем , так и другим
а тут уже у каждого абрама - своя программа

А у меня, таких как раз много случаев, т.к. я занимаюсь в основном администрированием и оптимизацией производительности, а не разработкой.

Я немного выше кейсы использования отредактировал, почитайте.
Там кроме нагрузки, есть ещё один важный момент - снятие профайлинга пользовательских запросов, которое ну очень уж "дорого" на xdebug, и к тому же, очень сложно будет разобраться в огромном количестве трейсов, которые он сгенерит.
А запросы по произвольному условию в скрипт так и вообще не особо и снимешь xdebug.