Влияние на производительность использования aop
-
10-07-2019 - |
Вопрос
Мы начали использовать Spring AOP для сквозных аспектов нашего приложения (на данный момент безопасность и кэширование).
Моего менеджера беспокоит влияние этой технологии на производительность, хотя он полностью осознает ее преимущества.
Мой вопрос: сталкивались ли вы с проблемами производительности, вызванными использованием aop (в частности, Spring aop)?
Решение
Пока вы контролируете свой AOP, я думаю, что это эффективно. В любом случае у нас были проблемы с производительностью, поэтому по собственным причинам мы не имели полного контроля над ним;) Это было главным образом потому, что важно, чтобы любой, кто пишет аспекты, имел полное понимание всех других аспекты в системе и как они взаимосвязаны. Если вы начнете делать "умный" вещи, которые вы можете перехитрить себя в один миг. Выполнение умных вещей в большом проекте с большим количеством людей, которые видят только небольшие части системы, может быть очень опасным с точки зрения производительности. Этот совет, вероятно, применим и без AOP, но AOP позволяет вам по-настоящему изящно выстрелить себе в ногу.
Spring также использует прокси для манипуляций с областью и вот область, где легко получить нежелательные потери производительности.
Но, учитывая, что у вас есть контроль, единственной реальной проблемой в AOP является эффект отладки.
Другие советы
Когда я использовал это, я не сделал - но тогда мое приложение не ваше приложение.
Если вы используете его для вызовов, которые используются в очень узком цикле, есть возможность для значительного снижения производительности. Если он просто используется для проверки безопасности один раз для каждого запроса и кеширования различных вещей, я не могу понять, насколько это может быть значительным, но именно поэтому вам следует профилировать и тестировать ваше приложение.
Я понимаю, что " сопоставь со своим приложением " возможно, это не тот ответ, который вы искали, но вполне может оказаться, что вы догадались, что вы получите:)
Если вы используете AOP на основе прокси, вы говорите об 1 дополнительном вызове метода Java для каждого примененного аспекта. Влияние на производительность там довольно незначительное. Единственная реальная проблема - создание прокси, но обычно это происходит только один раз при запуске приложения. В блоге SpringSource есть отличный пост на эту тему:
http://blog.springsource.com / 2007/07/19 / развенчания-мифы-прокси-прицельная / производительность
Теоретически, если вы используете АОП и делаете то, что могли бы сделать с жесткой связью, не возникает проблем с производительностью, никаких накладных расходов и дополнительных вызовов методов, если только вы не переплетаетесь просто так.AOP Framework предлагает вам способ устранить жесткую связь и факторизовать ваши сквозные задачи.
На практике AOP Framework может вводить 3 типа накладных расходов:
- время пожара
- механик по перехвату
- интеграция потребителей (способ разработки совета)
Для получения более подробной информации вы можете обратиться к когда выполняется код AOP.
Просто будьте осторожны с реализацией совета, потому что трансверсальный код — это искушение для упаковки/распаковки и отражения (дорогое с точки зрения производительности).
Без структуры АОП (жесткой связи между вашими сквозными проблемами) вы можете легче разрабатывать предполагаемые советы (специально для каждого лечения) без упаковки/распаковки и размышлений.
Вы должны знать, что большинство AOP Framework не предлагают способа избежать полной упаковки/распаковки и отражения.
Я разработал один, чтобы удовлетворить большинство недостающих потребностей, сосредоточив внимание на трех вещах:
- удобный для пользователя (легкий, простой в освоении)
- прозрачный (не включается ломающий код)
- эффективный (без упаковки/распаковки, без отражения в номинальном коде пользователя и хорошая механика перехвата)
Вы можете найти мой проект с открытым исходным кодом здесь: Puresharp API .net 4.5.2+ ранее NConcern .NET AOP Framework
Вы когда-нибудь задумывались об инструментах АОП, которые добавляют аспекты к объекту во время выполнения, когда вам это нужно? Существует один вариант для .net " Добавить аспекты к объекту с помощью динамического декоратора " (Http://www.codeproject.com/KB/architecture/aspectddecorator.aspx). Я полагаю, что вы можете написать аналогичный для Java.
Если вы используете какую-то одну инфраструктуру для аспектов, могут быть некоторые проблемы с производительностью. Далее, если вы создаете абстракцию над какой-то одной структурой, а обработка аспектов выполняется из среды, тогда очень трудно найти причину проблемы, связанной с проблемы с производительностью . Если вы действительно беспокоитесь о производительности и о небольшом временном интервале, я предлагаю написать свои собственные аспекты. Никто не хочет изобретать колесо, но иногда для лучшего это может быть лучше. Вы можете написать собственную реализацию абстракции альянса АОП.
Я использовал Spring AOP в пакетном процессе моего текущего проекта для управления транзакциями в базе данных.
Сначала предполагалось, что проблем с производительностью не будет, но мы не придумали уравнение, которое мы называли базой данных тысячи раз. один аспектный вызов в aop не сильно влияет на производительность, но умножает это на тысячи, и оказывается, что новая система оказалась хуже старой из-за этих дополнительных вызовов методов.
Я бы сказал, что aop - отличная система для использования, но постарайтесь принять к сведению, сколько вызовов методов добавлено в ваше приложение