Microsoft MVP성태의 닷넷 이야기
.NET Framework: 283. MEF를 ASP.NET에 성능 손실 없이 적용하려면? [링크 복사], [링크+제목 복사],
조회: 18193
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)

MEF를 ASP.NET에 성능 손실 없이 적용하려면?

어제의 이야기에 이어서.

MEF가 적용된 ASP.NET 웹 사이트를 제니퍼 닷넷으로 모니터링 해본 결과!
; https://www.sysnet.pe.kr/2/0/1203

그래도 왠지 찜찜합니다. 다시... 코드를 살펴보겠습니다.

public void Initialize(object o)
{
    var batch = new CompositionBatch();
    batch.AddPart(o);

    try {
        DirectoryCatalog directoryCatalog = new DirectoryCatalog(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "bin"));
        var _container = new CompositionContainer(directoryCatalog);
        _container.Compose(batch);
    } 
    catch (Exception ex)
    {
        System.Diagnostics.Trace.WriteLine(ex.ToString());
    }
}

뭔가... static으로 지정해 놓고 재사용하면 되지 않을까요? 우선, CompositionBatch는 ... 대상이 아닙니다. 왜냐하면 object 인자로 들어오는 인스턴스 자체가 ASP.NET Request 마다 생성되는 웹 페이지 인스턴스이기 때문에 CompositionBatch를 static으로 두는 것은 의미가 없습니다. CompositionContainer는 어떨까요? 아쉽게도 Container는 Compose 메서드 호출을 담당할 뿐 사실 거의 하는 일이 없기 때문에 재사용할 만한 여지가 없습니다.

그렇다면... 남은 것은 DirectoryCatalog 인스턴스가 되겠군요. 잠시 생각해 보면 적절한 후보로 여겨집니다. 왜냐하면 ASP.NET 요청이 들어올 때 마다 매번 /bin 폴더를 검색해서 ComposableParts를 구성할 의미가 없기 때문입니다.

C# Singleton 인스턴스 생성
; https://www.sysnet.pe.kr/2/0/896

위의 글에 따라, Singleton 인스턴스로 다음과 같이 cache를 하는 식으로 코드를 수정해 보았습니다.

public class MEFHelper
{
    static object syncObject = new object();

    static DirectoryCatalog _directoryCatalog;
    DirectoryCatalog DirectoryCatalog
    {
        get
        {
            if (_directoryCatalog == null)
            {
                lock (syncObject)
                {
                    if (_directoryCatalog == null)
                    {
                        _directoryCatalog = new DirectoryCatalog(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "bin"));
                    }
                }
            }

            return _directoryCatalog;
        }
    }


    public void Initialize(object o)
    {
        var batch = new CompositionBatch();
        batch.AddPart(o);

        try {
            var _container = new CompositionContainer(DirectoryCatalog);
            _container.Compose(batch);
        } catch (Exception ex)
        {
            System.Diagnostics.Trace.WriteLine(ex.ToString());
        }
    }
}

다시 default.aspx를 방문해 보면... 최초로 뜨는 경우에는 약간 느리지만 이후에 재방문 했을 때는 체감속도가 눈에 띄게 빨라졌습니다. 확인을 위해 제니퍼 닷넷의 프로파일링 화면을 보면,

mef_perf_imp_1.png

응답시간은 말할 필요도 없고 CPU 사용량도 여느 ASP.NET 웹 페이지 처리하는 수준으로 내려갔습니다.

음... ^^; 하루만에 결론이 바뀌는군요.

"MEF는 ASP.NET에 적용해도 전혀 손색이 없습니다."

단지, 최초 한 번의 요청에서는 시간이 좀 걸릴 뿐!




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 2/11/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2011-12-22 12시42분
[khj] MEF를 사용하는 가장 큰 목적은 다이나믹하게 필요한 어셈블리를 구성하는 것인데 말씀하신대로 스태틱으로 구성하는건 원래 MEF의 사용목적을 감쇄시킨다는 생각이 듭니다.
[guest]
2011-12-22 02시35분
khj 님의 의견이 틀린 것은 아니지만... 약간 오버해서 판단하신 것이 아닌가 생각됩니다.

khj 님이 원하는 '다이나믹'은 어느 정도인가요? 요청이 발생할 때마다 새롭게 덮어써졌을지도 모르는 DLL을 매번 로드해서 확인하는 것은 아닐 것입니다.

일단, 윈폼에서 MEF를 적용한 경우를 예로 들어볼까요? 대개의 경우 응용 프로그램 시작 시에 DirectoryCatalog와 CompositionContainer를 인스턴스화 하고 필요한 경우마다 Compose를 호출할 것입니다. 즉, 윈폼에서조차도 Compose를 호출해야 할 때마다 매번 DirectoryCatalog와 CompositionContainer를 새로 생성하지는 않습니다. 결국 이런 상황은 위의 ASP.NET 적용과 크게 다르지 않은데,,, khj 님은 그렇게 구현된 윈폼 응용 프로그램에서도 MEF의 사용목적이 감쇄된다고 생각하시나요? (혹은, 위와는 다르게 DirectoryCatalog와 CompositionContainer 인스턴스를 관리하시나요?)

사실, 윈폼 + MEF에서 로드된 대상 DLL이 이미 인스턴스화 되었다면 기존 DLL이 잠겨버리기 때문에 덮어써서 '동적'으로 로드하는 것 자체가 안됩니다. (아니면 파일명을 바꿔서 해야겠지요.)

게다가... 사용목적을 감쇄시킨다는 고려를 하기 전에 이미 Page_Load 마다 처리하는 것은 사용할 수 없을 정도의 수준이 되어버렸다는 것을 간과할 수 없습니다.
정성태
2011-12-22 02시47분
[khj] MEF가 추구하는 목적은 다른 여타 IOC 컨테이너들과는 조금 다르다고 생각합니다.
말씀하신 윈폼의 예제는 일반적인 IOC 컨테이너들이 하고자 하는바가 아닐까요? MEF의 용도와는 조금 다르다고 생각합니다.
MEF는 런타임에 사용하려는 어셈블리에 대한 정보가 전혀 없을 경우에도 그 어셈블리들을 사용 가능케 하려는 목적이 큽니다.(참조: http://stackoverflow.com/questions/108116/mef-managed-extensibility-framework-vs-ioc-di)
물론 말씀하신대로 Page_Load 시마다 DirectoryCatalog를 새로 구성하는 것은 성능상의 문제가 있습니다만, 말씀드린대로 MEF의 목적도 상쇄시키는 역효과도 있음을 말씀드리고 싶습니다.
어쩔수없이 그렇게 해야한다면 다이나믹한 어셈블리 로딩도 보장할 수 있는 다른 방법도 강구가 되야할 거 같네요.
[guest]
2011-12-22 03시37분
혹시 'MEF가 추구하는 목적'에 맞는 간단한 형식의 (윈폼이든, ASP.NET이든 상관없이) 예제를 구할 수 있을까요? (링크도 상관없습니다.) khj 님의 생각대로 그 예제들이 구현되어 있는지 한번 확인하면서 이야기를 더 나누는 것이 좋을 것 같다는 생각이 듭니다.
정성태
2011-12-22 05시19분
[lancers] 일단 MEF를 사용하는 가장 큰 목적이 런타임에 사용하려는 어셈블리에 대한 정보가 전혀 없을 때도 사용가능하게 하기 위한 것이라는 khj님의 의견에는 동감합니다.
딱 적합한 시나리오가 소위 말하는 플러그인들이죠. 예제는 다른 곳에서도 찾을 필요 없이 바로 VS2010이고...

하지만 그렇다고 해서 꼭 그렇게만 써야 하는 것도 아니지요. ^^
'사용하려는 어셈블리에 대한 정보를 사전에 얻을 수 있는 경우'에는 굳이 그런 방법으로 쓸 필요가 없는 것이죠.
예를 든 ASP.NET인 경우처럼, 사실 일반적인 경우에는 모두 사전에 얻을 수 있는 경우에 해당됩니다.

후자인 경우에 DirectoryCatalog를 실제 런타임 시에 사용하는 건 사실 좀 오버이거나 귀차니즘적인 성향이 큽니다. ㅎㅎ
그리고 물론 후자인 경우에 꼭 MEF를 써야 하는가라고 말하면 그렇지는 않습니다. 다만 취향일뿐.. ㅋㅋㅋ

어셈블리가 이미 로딩된 상태에서의 재구성은 좀 다른 얘기 같아요.
이건 MEF에서의 문제가 아니라 .NET CLR 자체가 가지는 약점이니까요.
사실 MEF가 동적 Discovery, Delay-Load, Recomposition과 같은 훌륭한 개념들을 가지고 있음에도 불구하고 CLR의 한계로 인해 아쉬운 면이 있습니다.
예를 들면 VS에서도 이미 로딩된 플러그인을 업데이트하려고 하면 VS를 재시작해야 하는 아픔들이 있지요.

참고로 이미 인스턴스화된 어셈블리를 덮어써서 동적으로 로드하는 것도 가능합니다. (파일명 안 바꿔도.. ㅎㅎ)
엄밀히 말하면 이미 로드된 어셈블리를 언로드할 수 있는 방법이 없다는 것이고.. 덮어써서 로드하는 것도 가능하긴 한데 많은 귀차니즘을 수반한다는거고.. ^^
[guest]
2011-12-22 11시06분
사실, 제가 마지막 덧글에서 'MEF가 추구하는 목적에 맞는 간단한 형식의 예제'를 요구한 이유는, 그런 '간단한 예제'들 중 그 어떤 것도 khj 님이 요구하는 수준의 dynamic한 DLL 관리는 없을 것이라는 가정에서 한 것입니다. 일례로, Microsoft에서 제공하는 MEF 예제조차도 DirectoryCatalog와 CompositionContainer를 인스턴스로 들고 있는 식입니다.

Managed Extensibility Framework Overview
; https://docs.microsoft.com/en-us/dotnet/framework/mef/

(위의 예제를 보고 따라한 모든 개발자들이 DirectoryCatalog와 CompositionContainer를 Compose 메서드를 호출할 때마다 당연히 매번 초기화해야 한다고 알고 있다고 주장하시면... 저는 더 이상 할말이 없습니다. ^^;)

lancers 님의 의견대로 '엄밀히 말하면 이미 로드된 어셈블리를 언로드할 수 있는 방법이 없다는 것이고.. 덮어써서 로드하는 것도 가능하긴 한데 많은 귀차니즘을 수반한다'는 것이고 그 정도면 이미 MEF를 위한 wrapper 코드를 꽤나 작성한 수준이 됩니다. 제가 이번 글에서 쓴 내용은 단지 몇 줄의 코드로 'ASP.NET에서 현실적으로 사용할 수 있는 수준의 MEF' 구현을 소개하는 것이고.
정성태
2011-12-29 07시08분
[누구게~요?] 헙... 이토록 엄청난...
지인이라고 소개받은 저입니다.

바쁜 일정과 짧은 지식에 MEF 를 적용한 저로서는 일단 MEF 를 잘 사용하려면 Cache 도 Cache 지만 Export 하는 DLL 의 갯수가 관건이라 생각하고
일을 진행하고 있었는데... 간만에 들른 이곳에서 이토록 진지한 토론이 벌어지는 지 몰랐습니다.

고수님들의 진지한 토론을 엿들을 수 있어 영광입니다.
(일만 벌리고 도망가는 듯한 기분... ㅋㅋ 도망갑니다. ㅋㅋㅋ)

행복한 하루되셔요...
[guest]

1  2  3  4  5  6  7  8  9  10  11  12  13  14  [15]  ...
NoWriterDateCnt.TitleFile(s)
13258정성태2/13/20234309오류 유형: 846. .NET Framework 4.8 Developer Pack 설치 실패 - 0x81f40001
13257정성태2/13/20234376.NET Framework: 2094. C# - Job에 Process 포함하는 방법 [1]파일 다운로드1
13256정성태2/10/20235221개발 환경 구성: 665. WSL 2의 네트워크 통신 방법 - 두 번째 이야기
13255정성태2/10/20234555오류 유형: 845. gihub - windows2022 이미지에서 .NET Framework 4.5.2 미만의 프로젝트에 대한 빌드 오류
13254정성태2/10/20234446Windows: 223. (WMI 쿼리를 위한) PowerShell 문자열 escape 처리
13253정성태2/9/20235226Windows: 222. C# - 다른 윈도우 프로그램이 실행되었음을 인식하는 방법파일 다운로드1
13252정성태2/9/20234044오류 유형: 844. ssh로 명령어 수행 시 멈춤 현상
13251정성태2/8/20234482스크립트: 44. 파이썬의 3가지 스레드 ID
13250정성태2/8/20236311오류 유형: 843. System.InvalidOperationException - Unable to configure HTTPS endpoint
13249정성태2/7/20235172오류 유형: 842. 리눅스 - You must wait longer to change your password
13248정성태2/7/20234221오류 유형: 841. 리눅스 - [사용자 계정] is not in the sudoers file. This incident will be reported.
13247정성태2/7/20235109VS.NET IDE: 180. Visual Studio - 닷넷 소스 코드 디버깅 중 "Decompile source code"가 동작하는 않는 문제
13246정성태2/6/20234254개발 환경 구성: 664. Hyper-V에 설치한 리눅스 VM의 VHD 크기 늘리는 방법 - 두 번째 이야기
13245정성태2/6/20234819.NET Framework: 2093. C# - PEM 파일을 이용한 RSA 개인키/공개키 설정 방법파일 다운로드1
13244정성태2/5/20234158VS.NET IDE: 179. Visual Studio - External Tools에 Shell 내장 명령어 등록
13243정성태2/5/20235015디버깅 기술: 190. windbg - Win32 API 호출 시점에 BP 거는 방법 [1]
13242정성태2/4/20234448디버깅 기술: 189. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.UnauthorizedAccessException
13241정성태2/3/20233930디버깅 기술: 188. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.IO.FileNotFoundException
13240정성태2/1/20234084디버깅 기술: 187. ASP.NET Web Application (.NET Framework) 프로젝트의 숨겨진 예외 - System.Web.HttpException
13239정성태2/1/20233750디버깅 기술: 186. C# - CacheDependency의 숨겨진 예외 - System.Web.HttpException
13238정성태1/31/20235840.NET Framework: 2092. IIS 웹 사이트를 TLS 1.2 또는 TLS 1.3 프로토콜로만 운영하는 방법
13237정성태1/30/20235502.NET Framework: 2091. C# - 웹 사이트가 어떤 버전의 TLS/SSL을 지원하는지 확인하는 방법
13236정성태1/29/20235109개발 환경 구성: 663. openssl을 이용해 인트라넷 IIS 사이트의 SSL 인증서 생성
13235정성태1/29/20234665개발 환경 구성: 662. openssl - 윈도우 환경의 명령행에서 SAN 적용하는 방법
13234정성태1/28/20235746개발 환경 구성: 661. dnSpy를 이용해 소스 코드가 없는 .NET 어셈블리의 코드를 변경하는 방법 [1]
13233정성태1/28/20237103오류 유형: 840. C# - WebClient로 https 호출 시 "The request was aborted: Could not create SSL/TLS secure channel" 예외 발생
1  2  3  4  5  6  7  8  9  10  11  12  13  14  [15]  ...