Влияние на производительность использования AOP

Question

Мы начали использовать spring aop для сквозных аспектов нашего приложения (безопасность и кеширование на данный момент).

Мой менеджер обеспокоен влиянием этой технологии на производительность, хотя он полностью осознает преимущества.

Мой вопрос, встречались ли у вас проблемы с производительностью, вызванные использованием aop (особенно spring aop)?

Answer 1

Пока вы контролируете вашего AOP, я думаю, что это эффективно. В любом случае у нас были проблемы с производительностью, поэтому, по собственным соображениям, мы не полностью контролировали;) Это было главным образом потому, что важно, чтобы любой, кто пишет аспекты, имел полное понимание всех других аспектов в системе и как они взаимосвязаны. Если вы начинаете делать «умные» вещи, вы можете перехитрить себя в один миг. Выполнение умных вещей в большом проекте с большим количеством людей, которые видят только небольшие части системы, может быть очень опасным с точки зрения производительности. Этот совет, вероятно, применим и без АОП, но АОП позволяет вам по-настоящему изящно выстрелить себе в ногу.

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

Но, учитывая, что у вас есть контроль, единственная реальная болевая точка с AOP - это эффект отладки.

Answer 2

Если производительность будет иметь значение, мы использовали AspectJ с большим эффектом.

Поскольку он использует переплетение байт-кода (время компиляции и время выполнения имеют существенное значение), это одна из самых быстрых сред AOP. См .: AOP Benchmarks

Answer 3

Когда я использовал это, я не сделал - но тогда мое приложение не ваше приложение.

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

Я понимаю, что "измерить с вашим приложением", вероятно, не тот ответ, который вы искали, но вполне может быть, что вы догадались, что вы получите:)

Answer 4

Если вы используете AOP на основе прокси, вы говорите об 1 дополнительном вызове метода Java для каждого примененного аспекта. Влияние на производительность там довольно незначительное. Единственная реальная проблема - создание прокси, но обычно это происходит только один раз при запуске приложения. В блоге SpringSource есть отличный пост на эту тему:

http://blog.springsource.com/2007/07/19/debunking-myths-proxies-impact-performance/

Answer 5

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

На практике AOP Framework может вводить 3 типа издержек:

• противопожарное время
• Механик перехвата
• потребительская интеграция (способ выработки совета)

Для получения более подробной информации вы можете обратиться к когда код выполняется, если это .

Просто будьте осторожны, когда вы реализуете совет, потому что трансверсальный код является соблазном для упаковки / распаковки и отражения (дорогой с точки зрения производительности).

Без AOP Framework (жестко увязывающего ваши межсекторальные задачи) вы сможете легче разрабатывать предполагаемые советы (выделенные для каждой процедуры) без упаковки / распаковки и отражения.

Вы должны знать, что большинство AOP Framework не предлагают способ полностью избежать упаковки / распаковки и отражения.

Я разработал один для удовлетворения большинства недостающих потребностей, сосредоточенный на 3 вещах:

• удобный (легкий, легкий в освоении)
• прозрачный (без взлома кода для включения)
• эффективный (без упаковки / распаковки, без отражения в номинальном коде пользователя и хорошей механике перехвата)

Мой проект с открытым исходным кодом находится здесь: Puresharp API .net 4.5.2 + ранее NConcern .NET AOP Framework

Answer 6

Если вы используете какой-то один фреймворк для аспектов, могут быть некоторые проблемы с производительностью. Далее, если вы создаете абстракцию над чем-то одним фреймворком, а обработка аспектов выполняется из фреймворка, тогда очень трудно найти причину проблемы, связанной с проблемы с производительностью . Если вы действительно беспокоитесь о производительности и о небольшом временном интервале, я предлагаю написать собственные аспекты. Никто не хочет изобретать колесо, но иногда для лучшего это может быть лучше. Вы можете написать собственную реализацию абстракции альянса АОП.

Answer 7

Вы когда-нибудь задумывались об инструментах АОП, которые добавляют аспекты к объекту во время выполнения, когда вам это нужно? Существует один для .net «Добавление аспектов к объекту с помощью динамического декоратора» (http://www.codeproject.com/KB/architecture/aspectddecorator.aspx). Я полагаю, что вы можете написать аналогичный для Java.

Answer 8

Я использовал Spring AOP в пакетном процессе в моем текущем проекте для управления транзакциями базы данных.

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

Я бы сказал, что aop - отличная система для использования, но постарайтесь принять к сведению, сколько вызовов методов добавлено в ваше приложение