Comments 8
А не пробовали аспекты для этих целей?
С аспектами не так все просто, так как нужно где-то хранить граф вызовов и прочую информацию. Плюс спринг создает аспекты только для бинов, а у нас домены таковыми не являлись. На самом деле у нас на проекте либа ипользовалась при помощи аспекта: метод репозитория перехватывался аспектом и возвращаемый объект отдавался в MethodInvocationRecorder#record, примерно так:
public Object intercept (final ProceedingJoinPoint pjp) throws Throwable {
MethodSignature signature = (MethodSignature) pjp.getSignature();
return methodInvocationRecorder.record(signature.getMethod(), pjp.proceed()); // start recording
}
public Object intercept (final ProceedingJoinPoint pjp) throws Throwable {
MethodSignature signature = (MethodSignature) pjp.getSignature();
return methodInvocationRecorder.record(signature.getMethod(), pjp.proceed()); // start recording
}
Можно использовать не только нативные аспекты от Спринга, например AspectJ можно очень гибко настроить.
Нагрузку создаёт не доступ к объекту, а выполнение SQL. Поэтому логично логировать все SQL-запросы и смотреть, какие лишние, а какие можно объединить в один. Т.е. лечить проблему, а не симптомы.
По прядку.
Нагрузку создаёт не доступ к объекту, а выполнение SQL.
В статье я писал про MongoDB, это noSQL база. Понятно что сам вызов метода ничего не стоит, но вызов метода, который обращается к lazy полю приводит к запросу к базе чтобы загрузить данные. У нас все запросы логировались, но по ним было трудно понять, был ли это вызов сделан используя непосредственно репозиторий или же этот метод выл вызван в процессе работы lazy-loading механизма, который так же использует репозитории для загрузки.
Поэтому логично логировать все SQL-запросы и смотреть, какие лишние, а какие можно объединить в один. Т.е. лечить проблему, а не симптомы.
Мы симптомы не лечили, мы старались избежать вызов lazy полей там где это не нужно и получить информацию о страницах где есть неоптимальные вызовы.
Сами запросы к монге были заимпруваны настолько насколько это было возможно. К слову, репозитории, которые использовали монго не уступали по производительности репозиторям использующим Oracle Coherence для тех же кейсов. Область применения, которую я описал в статье, специфична для нашего проекта и написал я о это что бы показать какая проблема была у нас на проекте и как мы ее решили при помощи разработанной библиотеки. Это скорее для того что бы рассказать как появилась идея создания jmspy. а по факту использовать ее можно в разных целях.
Нагрузку создаёт не доступ к объекту, а выполнение SQL.
В статье я писал про MongoDB, это noSQL база. Понятно что сам вызов метода ничего не стоит, но вызов метода, который обращается к lazy полю приводит к запросу к базе чтобы загрузить данные. У нас все запросы логировались, но по ним было трудно понять, был ли это вызов сделан используя непосредственно репозиторий или же этот метод выл вызван в процессе работы lazy-loading механизма, который так же использует репозитории для загрузки.
Поэтому логично логировать все SQL-запросы и смотреть, какие лишние, а какие можно объединить в один. Т.е. лечить проблему, а не симптомы.
Мы симптомы не лечили, мы старались избежать вызов lazy полей там где это не нужно и получить информацию о страницах где есть неоптимальные вызовы.
Сами запросы к монге были заимпруваны настолько насколько это было возможно. К слову, репозитории, которые использовали монго не уступали по производительности репозиторям использующим Oracle Coherence для тех же кейсов. Область применения, которую я описал в статье, специфична для нашего проекта и написал я о это что бы показать какая проблема была у нас на проекте и как мы ее решили при помощи разработанной библиотеки. Это скорее для того что бы рассказать как появилась идея создания jmspy. а по факту использовать ее можно в разных целях.
Интересно, если доступ к полю происходит много раз, все эти вызовы равнозначно залоггируются, хотя нагрузка только при первом вызове?
Неплохо, если бы логгер обращения к базе фиксировал бы также stack trace. Тогда, сгруппировав по трейсам, можно вычислить, откуда чаще всего приходят lazy-подгрузки.
но по ним было трудно понять, был ли это вызов сделан используя непосредственно репозиторий или же этот метод выл вызван в процессе работы lazy-loading механизма, который так же использует репозитории для загрузки.
Неплохо, если бы логгер обращения к базе фиксировал бы также stack trace. Тогда, сгруппировав по трейсам, можно вычислить, откуда чаще всего приходят lazy-подгрузки.
Интересно, если доступ к полю происходит много раз, все эти вызовы равнозначно залоггируются, хотя нагрузка только при первом вызове?
да, поля по lazy инициализируются только при первом вызове, но только для того же объекта. Если объект новый, то lazy загрузка снова отработает для тех же самых полей. В логах видно, что запрос был инициирован из за lazy-loading'a, но тут вопрос: был ли это неоптимальный вызов или же он был осмысленным?. Были места на страницах где происходила загрузка ради того что бы просто достать id или name, а эти поля уже есть в рутом объекте, так что нет смысла грузить лишние данные.
Неплохо, если бы логгер обращения к базе фиксировал бы также stack trace. Тогда, сгруппировав по трейсам, можно вычислить, откуда чаще всего приходят lazy-подгрузки.
Да я думал об этом, но опять же эти логи надо как-то обрабатывать и делать это таким образом, что бы информация была полезной и адекватной. Что бы разработчик взглянул, быстро нашел нужное место и пофиксал проблему. Обработка еще усложняется из за того что в стектрейсах будет куча вызовов из за lazy-loading механизма. На мой взгляд задача нетривиальная, да и результат сомнителен. Кстати jmspy тоже пишет стектрейсы, но не особо они нам помогли в нашей проблеме.
Прикольная штучка. Только если дерево вызовов будет чуть поглубже, то с ним работать будет довольно трудно в UI.
Вы попробуйте XRebel, может это оно то самое что вам надо?
Вы попробуйте XRebel, может это оно то самое что вам надо?
Sign up to leave a comment.
JMSpy — шпион за вызовами методов