.net 프로젝트에서 aop을 사용하여 성능 문제가 발생했습니다.

Question

큰 .net 프로젝트에서 PostSharp 및 Spring.NET을 사용하면 성능에 영향이 있습니다 (약 50 만명의 활성 사용자).

기본적으로 나는 다음과 같은 것을 원한다 : 나는 사용자 보고서를 만들 때 50 만회 동안 로깅을 생성하고 싶지 않다. 그러나 사용자가 시스템을 사용하면 그 사람의 활동을 기록하고 싶습니다. 대부분의 AOP 도구에는 이러한 유연성이 없습니다.

개별 개체에 애스펙트를 첨부 할 수있는 방법이 있습니까? 또는 런타임에 애스펙트를 켜거나 끕니까?

Answer 1

PostSharp와 Spring.NET의 성능을 함께 논의 할 수 없습니다. PostSharp는 컴파일 타임 짜기를 사용하고 Spring.NET은 런타임 짜기를 사용합니다. PostSharp가 컴파일 타임에만 AOP 오버 헤드를 추가하고 런타임시 Spring.NET 만 추가한다는 것을 의미합니다. 더 많은 통찰력을 얻으려면 articles from SharpCrafters을 읽으십시오.

AOP의 핵심 기능 중 하나는 포인트 컷입니다. Pointcut은 주어진 타입/메소드 등을 위해 aspect를 사용할 것인지를 선택하는 술어로 생각할 수 있습니다. 따라서 시스템의 특정 지점에서만 로깅 aspect를 사용하기 위해 항상 타입 구조와 pointcut을 생성 할 수 있습니다. 이것은 AOP가 작동하는 방법입니다.

런타임시 애스펙트 켜기/끄기에 대해 - 코드에 컴파일 된 포스트 샤프의 경우, 어떤 트릭도 없이는 불가능하다고 생각합니다. Spring.NET의 경우 더 쉬울 것이지만 여전히 필요한 이유를 알 수는 없습니다.

Answer 2

aop-logging-issues 로깅 성능 오버 헤드는 수행 방법에 따라 다릅니다.

코드에 로깅 권고를 주입하려고한다고 가정합니다. 동적 AOP는 인터페이스의 가상 메소드

• 및
• 만 가능하다.

아마도 컴파일 시간은 일 것입니다.

나는 post-sharp가 어떻게하는지 알지 못한다. compiletime linfu-aop을 사용하면 모든 메소드가 사전 실행 및 사후 실행을 가져 오며, 여기서 aop-aspects가 실행되면 동적으로 결정됩니다. 이 트릭은 실제 가상이 아닌 가상 메소드에서 restrictins를 제거합니다. log4.net 공급자를 사용을 common.logging와 로깅 -

나는 manuall (= 비 AOP을) 할 것을 선호합니다. 로깅이 비활성화 된 경우이 솔루션은 런타임 오버 헤드를 갖습니다.. 로깅 활성화/비활성화는 "모든 데이터 계층 활동이 sql"이지만 "모듈 xyz의 sql"은 말할 수없는 구성 파일 만 재 컴파일하지 않고도 명확하게 수행 할 수 있습니다.

값 비싼 stacktrace-analysis (어떤 클래스이고 debug/trace, Info, ....에서 나를 위해 로그온하거나 나를 위해)는 클래스 당 한 번만 수행됩니다.

사용되지 않는 로깅은 값이 싼 변수 boolen 평가 1 개를 더한 값으로 다시 채울 수 있습니다.크기 최적화를위한이 속도는

if (logger.IsDebugEnabled) 
    call anonymous method that does 
     the expensive string formatting 

Answer 3

PostSharp 및 Spring.NET에 대한 나의 이해는 당신이 정의하는 것이 당신의 측면, 포인트 컷, 또는 유사한 무언가로 컴파일 된

logger.Debug(m => m("... costly string formatting ")); 

구문에 의해 처리 될 수 있습니다 디자인 타임에 수업에 무엇이든 할 수 있습니다. 애스펙트를 켜거나 끄거나 포인트 컷 (pointcut)을 변경하는 것과 관련하여 클래스의 객체를 사용할 때 할 수있는 일은 많지 않습니다.

클래스 디자인 타임에 정의한 것을 얻을 수 있습니다. 아무리 당신이 하나의 물체를 사용하거나 그 물체를 백만개의 물체로 사용하십시오. 당신은 그들을 사용하기 위해 매우 조심해야합니다. 그렇지 않으면, 발에 발을 쏠 수 있습니다.

정말 원하는 것은 클래스 수준이 아닌 객체 수준의 측면을 다루는 AOP 도구입니다. 기사는 Add Aspects to Object Using Dynamic Decorator입니다.

나를 위해, 측면은 시스템 요구 사항입니다. 시스템 요구 사항은 운영 요구 사항이며 런타임에 개체가 사용될 때 개체 수준에서 가장 잘 처리됩니다.

솔직히 말하면, 대부분의 AOP 도구가 시스템 요구 사항을 수업 시간에 해결하려고하는 이유를 모르겠습니다. 왜 그렇게 오래 동안 입양이 제한적 이었는지 설명 할 수 있습니다.

Answer 4

나는 좋은 성능을 가진 새로운 오픈 소스 프로젝트 인 NConcern .NET AOP Framework에 적극적으로 참여하고 있습니다. 이 런타임 AOP 프레임 워크는 비가 상 메소드 (정적 포함)에 코드를 삽입 할 수 있으며 런타임에 첨부하거나 분리 할 수 ​​있습니다.

기존 AOP 프레임 워크의 대부분은 동일한 차단 기술을 기반으로합니다. 컴파일 시간 AOP 프레임웍 사후 편집에 재기록 런타임 구현

IL위한

• 프록시 (반사 장식) 또는 ContextBoundObject/RemotingRealProxy.

그렇기 때문에 런타임 대 컴파일 타임 구현에 대한 제한과 성능을 쉽게 결론 지을 수 있습니다.

그러나 이것은 치명적이지 않으며 독점적 인 주입 기술과 최신 소비자 API를 사용하여 매우 쉽고 효율적으로 구현할 수 있습니다.

내 구현은 런타임에 작동하며 제한이 거의없고 커플 링이 매우 낮으며 리플렉션 오버 헤드를 피함으로써 최대 성능을 유지하는 조언을 정의하는 내장 식 트리를 제공합니다.

나는이 주제에 대해 당신의 의견에 관심이 있습니다. 제품 개선에 도움이 될 수 있습니다.