Во-первых, панель timeline, которая уже была довольно полезной для улучшения производительности приложений, стала показывать потребление памяти:
Панель конфигурации теперь показывает информацию о языке:
Была добавлена новая панель routing, показывающая информацию об обработке правил роутинга запроса:
Новая панель user panel показывает различную информацию о залогиненом пользователе:
Спасибо всем, кто принял участи в релизе. Особенно Дмитрию Башкареву и Daniel Gomez Pan.
Полный список изменений, как обычно, можно посмотреть в CHANGELOG.
UPD: выпущена версия 2.0.9, исправляющая ошибки в новых панелях для не стандартных конфигураций приложений. CHANGELOG.
Комментарии (34)
smple
19.02.2017 23:14-8не понимаю зачем такие штуки вообще нужны, я думал они уже вымерли, на прод не поставить
почему не использовать xdebug и профилирование в том же xdebug или xhprof, ну или более современный отладчик который есть из коробки в стабильных версиях php (начиная с 5.6 вроде), http://phpdbg.com/
LDZ
20.02.2017 08:49+2Это нужно для быстрого анализа при разработке на локалке, а не для мониторинга или профилирования на проде
smple
20.02.2017 13:20-1Так если это локал (дев среда) то xdebug вполне может помочь, потому что если надобилась отладка то надо ковырять, а верить в то что чуть копнем и может бага закроется слишком оптимистично.
Еще полезный аргумент в пользу посмотреть sql запросы, так почему бы нормально не настроить логирование? и не посмотреть лог.
Возможно кому то это и удобно, но точно не мне, например один проект на yii, другой на ларе и везде разная отладка, это как отлаживать через var_dump все понимают что плохо, еще есть свой отладчик для symfony и тд.
Еще благодаря таким штукам есть шанс на то что то отвалится, например https://habrahabr.ru/post/322166/#comment_10079130
SamDark
20.02.2017 13:29+1Это отвалилось не благодаря штуке, а в самой штуке.
smple
20.02.2017 13:43Очень интересно когда один из контрибютеров, при возникновение проблемы, для анализа проблемы использует xdebug вместо инструмента который разрабатывается для анализа проблем(отладчик).
Я не хочу сказать что xdebug нельзя и тд, я просто хочу сказать что любой подобный инструмент (о котором говорится в статье) это лишь очень поверхностный анализ, применение которого довольно ограничено и изучения инструментов вроде xdebug, phpdbg или xhprof вполне может окупится и не будет необходимости в использование других инструментов. (скриншот в таске)
Я хочу сказать что у разработки в любом случае бывают отладчики и профилирование, для поиска узких или проблемных мест и их использование гораздо более глубое, чем отладка на уровне приложения.SamDark
20.02.2017 14:01XDebug не позволяет нормально получить картину по производительности (потому что сам её искажает очень сильно). Им совершенно не удобно собирать и анализировать SQL запросы. Да, есть инструменты под каждую СУБД вроде Neor Profiler, но это всё разные инструменты и надо их запускать десяток и читать каждый отдельно, чтобы получить общую картину. К тому же, не всё можно продублировать инструментом уже готовым. Тот же роутинг, например.
smple
20.02.2017 14:31вам видней, так как инструмент вы разрабатываете, им пользуются и кому то он нравится и возможно (скорей всего) он упрощает какие то частые действия и людям это нравится.
Но лично мне удобней, использовать отладчик если я что то отлаживаю или разрабатываю, если мне надо проанализировать sql запросы, мне удобней изменить логирование и проанализировать лог (если я увижу странные запросы, привет отладчик, при этом лог не только на стороне app но и бд если что), если у меня проблемы с производительностью(или что подобное) использовать profiling tool для анализа, а дальше опять привет отладчик чтобы все улучшить.
Именно этим вызвано мое не понимание к подобным инструментам, я не знаю где его применять, запускать просто если проблема не выявлена то расчехлять инструменты и анализировать там, зачем тогда его изучать? если можно сразу инструментами получить инфу, для мистического экономия времени? так на изучения инструмента уйдет время, помимо этого для другова fw будет другой инструмент(пусть похожий но все же) нет общего стандарта или инструмента и для нового fw изучать новый инструмент, а те подходы что я описал выше, помогают почти всегда, причем даже с разными языками программирования.SamDark
20.02.2017 15:52+1Да там изучать нечего. Один тулбар, пять панелек. Настраивать ничего не надо. В том же Symfony не сложнее. Изучается за вечер, а то и меньше.
Zhuravljov
21.02.2017 09:31Вечер, это сильно сказано. Секунды. И, там, где кто-то будет решать проблему, которая уже встала в полный рост, я не дам ей появиться еще на этапе разработки. Именно потому, что анализ многих моментов с помощью отладочной панели мне ничего не стоит.
smple
20.02.2017 14:41Единственный более менее удобный способ использования инструмента я вижу в том чтобы люди далекие от программирования могли сообщить хоть какую то информацию и проблеме, например менеджер в случае ошибки мог примерно увидеть почему она возникла и кого пнуть, но такое на бой не поставишь.
Ну или я просто не достаточно хорошо знаю ваш инструмент и вы сейчас приведете много удобных примеров, только учитывайте что это будет в группе людей (разработчиков) которые понимают что такое логирование, отладка и профилирование.SamDark
20.02.2017 15:58+1Логирование даёт вам лог и не даёт инструментов для его анализа. Ни тебе графиков потребления памяти, ни времени выполнения, ни всех SQL запросов удобно рассортированных по длительности. То есть либо вы собираете себе какой-то набор для анализа, либо долго и нудно читаете логи, тратя в разы больше времени, чем могли бы...
Пошаговая отладка типа XDebug или dbg важна когда нам интересен контекст на каждом шаге. То есть шагнули, подумали, посмотрели переменные текущего контекста и т.д. Когда же нам просто надо посмотреть, как у нас произошло выполнение запроса, остановка на каждом шаге только мешает. Да, есть инструменты типа strace, но пользоваться ими несколько менее удобно. Профайлеры — штука прекрасная, но их надо настроить и уметь использовать. Причём на тот же SQL профайлер один, на PHP другой (да ещё и собирать данные одной тулзой, смотреть другой).
Djeux
20.02.2017 12:06+2Потому что это удобно и показывает многие вещи специфичные для фреймворка, которых в том же xdebug попросту нет. Те же запросы к базе на порядок проще смотреть в подобных фичах чем выискивать через xdebug
Zhuravljov
21.02.2017 09:53Вообще странно видеть сравнение yii2-debug и xdebug. Из общего у них только слово debug в названии.
tekord
20.02.2017 12:06+1Не использую xdebug как минимум потому, что он сильно снижает производительность. А панель дебаггера yii даёт достаточно информации и причём быстро. Без необходимости что-либо настраивать.
smple
20.02.2017 13:25начиная с версии 5.6 в комплекте идет phpdbg которые не отключается, просто он не так распротранен и не интегрирован в ide но возможно когда нибудь его интегрируют и как бы никому не мешает и не тормозит.
Lisio
20.02.2017 20:19+1Это как смотреть atop и ходить по /proc. Второе дает намного больше инфы, но бегло посмотреть первое намного проще и удобнее.
sam002
20.02.2017 02:39+1Не спешите обновляться, есть бага.
Валится serialize если для User используются какой-нибудь behavior в котором получение данных через функцию сделано. У меня сразу в трёх проектах проявилась((
Панель, конечно, огонь получается. Ещё бы фильтр по используемой памяти сделать в timeline и переключение пользователей. Планируется такое, SamDark?SamDark
20.02.2017 12:07Какой именно фильтр и что за переключение?
sam002
20.02.2017 12:56Фильтр — это в просмотре timeline рядом с Duration запипякать, например Memory.
А переключение — просто возможность из панели переключиться на другого пользователя без авторизации. Часто на работе такое использую, особенно когда надо проверять под разными ролями, т.е. пользователя на которого преключаюсь сразу выбираю с фильтром по ролям.SamDark
20.02.2017 13:08И то и то интересно и нет, мы об этом не думали. Кидайте отдельными issue или pull request-ами в репозиторий.
SamDark
21.02.2017 12:47+1Выпустил 2.0.9. Баги поправлены.
sam002
21.02.2017 19:33Спасибо. А глянь, пожалуйста, у меня такой вариант был решения для проверки панелей на использование. Вроде более универсально.
SamDark
22.02.2017 16:23+1А зачем прописывать панель и одновременно отключать её?
sam002
22.02.2017 18:44Типа какая-то панель работает/должна работать в зависимости от окружения или при определенной фазе луны. Как, например, пользователи. При ините чекнули и забыли про неё. Сейчас получается, что конкретно для core-панелей делаем проверку окружения, а кастомные реализации — крутись как хочешь.
batyrmastyr
20.02.2017 22:40+1Ура, уж и не ждал возвращения ProfileLogRoute из yii1, да ещё и на стероидах. ))
Merlen_Gross
Заголовок публикации "Debug 2.0.8" вводит в заблуждение. Предлагаю конкретизировать.
SamDark
Готово.