Мы начали использовать Spring aop для сквозных аспектов нашего приложения (на данный момент безопасность и кеширование).
Моего менеджера беспокоит влияние этой технологии на производительность, хотя он полностью осознает преимущества.
Мой вопрос, сталкивались ли вы с проблемами производительности, связанными с использованием aop (в частности, Spring aop)?
Я считаю, что пока вы контролируете свой АОП, это эффективно. В любом случае у нас были проблемы с производительностью, поэтому по собственному усмотрению мы не могли полностью контролировать;) Это было в основном потому, что важно, чтобы любой, кто пишет аспекты, имел полное понимание всех других Аспекты в системе и как они взаимосвязаны. Если вы начнете делать «умные» вещи, вы сможете в мгновение ока перехитрить себя. Делать умные вещи в большом проекте с большим количеством людей, которые видят только небольшие части системы, может быть очень опасно с точки зрения производительности. Этот совет, вероятно, применим и без АОП, но АОП позволяет выстрелить себе в ногу очень элегантными способами.
Spring также использует прокси для манипуляций с областью видимости, и это область, где легко получить нежелательные потери производительности.
Но, учитывая, что у вас есть контроль, единственная реальная проблема с АОП - это влияние на отладку.
Если производительность будет проблемой, мы очень эффективно использовали AspectJ.
Поскольку он использует переплетение байт-кода (время компиляции и время выполнения имеет большое значение), это одна из самых быстрых фреймворков АОП. См. Тесты AOP
Когда я его использовал, я этого не делал, но тогда мое приложение - это не ваше приложение.
Если вы используете его для вызовов, которые используются в очень узком цикле, есть возможность для значительного снижения производительности. Если он используется только для проверки безопасности один раз на запрос и кеширования различных вещей, я не понимаю, насколько это может быть значительным, но именно поэтому вам следует профилировать и тестировать свое приложение.
Я понимаю, что «измеряйте с помощью своего приложения», вероятно, не тот ответ, который вы искали, но вполне может быть тот, который, как вы догадались, получите :)
Если вы используете AOP на основе прокси, вы говорите об 1 дополнительном вызове метода Java для каждого применяемого аспекта. Влияние на производительность здесь весьма незначительно. Единственная реальная проблема - это создание прокси, но обычно это происходит только один раз при запуске приложения. В блоге SpringSource есть отличный пост по этому поводу:
http://blog.springsource.com/2007/07/19/debunking-myths-proxies-impact-performance/
Теоретически, если вы используете АОП, чтобы делать то, что вы могли бы сделать с жесткой связью, не будет проблем с производительностью, накладных расходов и дополнительных вызовов методов, если только вы не творитесь напрасно. AOP Framework предлагает вам способ устранить жесткую связь и разложить на множители общие проблемы.
На практике AOP Framework может вводить 3 типа накладных расходов:
Для получения дополнительных сведений см. when-is-aop-code-execution .
Просто будьте осторожны при реализации совета, потому что трансверсальный код - это соблазн для упаковки / распаковки и отражения (дорого с точки зрения производительности).
Без AOP Framework (жестко связывающего ваши сквозные проблемы) вы можете легче разрабатывать свои предполагаемые советы (предназначенные для каждого лечения) без упаковки / распаковки и размышлений.
Вы должны знать, что большинство 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 - отличная система для использования, но постарайтесь отметить, сколько вызовов методов добавлено в ваше приложение.
Спустя 11 лет после вопроса посмотрите, насколько ухудшилась эта ситуация.
Пример: подавляющее большинство думает, что это нормально и нормально помещать простую аннотацию @Transactional spring java к какому-либо методу и позволять Spring выполнять мост между вызывающими и проксируемыми компонентами вызываемого объекта. Теперь у них есть 20+ стековых фреймов «волшебного» кода, который невозможно отладить. Компилятор JIT быстро выходит за пределы возможностей и больше не может пытаться выполнить встраивание, или в конечном итоге приводит к переполнению памяти тоннами сгенерированных классов.
В эту эпоху «пользователей фреймворков» нет предела лени. Неудивительно, что время e2e для тривиальных http-вызовов увеличилось со 100 мс до 10 секунд. Неудивительно, что вам нужно 2 ГБ для запуска паршивого контейнера сервлетов, который раньше работал в 128 МБ. И не рассказывайте мне о стоимости протоколирования трассировки стека исключений ...
