Microsoft MVP성태의 닷넷 이야기
.NET Framework: 283. MEF를 ASP.NET에 성능 손실 없이 적용하려면? [링크 복사], [링크+제목 복사],
조회: 18390
글쓴 사람
정성태 (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]

... 16  17  [18]  19  20  21  22  23  24  25  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
13197정성태12/17/20224574.NET Framework: 2079. .NET Core/5+ 환경에서 XmlSerializer 사용 시 System.IO.FileNotFoundException 예외 발생하는 경우파일 다운로드1
13196정성태12/16/20224790.NET Framework: 2078. .NET Core/5+를 위한 SGen(Microsoft.XmlSerializer.Generator) 사용법
13195정성태12/15/20225255개발 환경 구성: 655. docker - bridge 네트워크 모드에서 컨테이너 간 통신 시 --link 옵션 권장 이유
13194정성태12/14/20225349오류 유형: 833. warning C4747: Calling managed 'DllMain': Managed code may not be run under loader lock파일 다운로드1
13193정성태12/14/20225466오류 유형: 832. error C7681: two-phase name lookup is not supported for C++/CLI or C++/CX; use /Zc:twoPhase-
13192정성태12/13/20225532Linux: 55. 리눅스 - bash shell에서 실수 연산
13191정성태12/11/20226440.NET Framework: 2077. C# - 직접 만들어 보는 SynchronizationContext파일 다운로드1
13190정성태12/9/20226932.NET Framework: 2076. C# - SynchronizationContext 기본 사용법파일 다운로드1
13189정성태12/9/20227785오류 유형: 831. Visual Studio - Windows Forms 디자이너의 도구 상자에 컨트롤이 보이지 않는 문제
13188정성태12/9/20226364.NET Framework: 2075. C# - 직접 만들어 보는 TaskScheduler 실습 (SingleThreadTaskScheduler)파일 다운로드1
13187정성태12/8/20226295개발 환경 구성: 654. openssl - CA로부터 인증받은 새로운 인증서를 생성하는 방법 (2)
13186정성태12/6/20224855오류 유형: 831. The framework 'Microsoft.AspNetCore.App', version '...' was not found.
13185정성태12/6/20225814개발 환경 구성: 653. Windows 환경에서의 Hello World x64 어셈블리 예제 (NASM 버전)
13184정성태12/5/20225008개발 환경 구성: 652. ml64.exe와 link.exe x64 실행 환경 구성
13183정성태12/4/20225012오류 유형: 830. MASM + CRT 함수를 사용하는 경우 발생하는 컴파일 오류 정리
13182정성태12/4/20225755Windows: 217. Windows 환경에서의 Hello World x64 어셈블리 예제 (MASM 버전)
13181정성태12/3/20225137Linux: 54. 리눅스/WSL - hello world 어셈블리 코드 x86/x64 (nasm)
13180정성태12/2/20225210.NET Framework: 2074. C# - 스택 메모리에 대한 여유 공간 확인하는 방법파일 다운로드1
13179정성태12/2/20224538Windows: 216. Windows 11 - 22H2 업데이트 이후 Terminal 대신 cmd 창이 뜨는 경우
13178정성태12/1/20225080Windows: 215. Win32 API 금지된 함수 - IsBadXxxPtr 유의 함수들이 안전하지 않은 이유파일 다운로드1
13177정성태11/30/20225800오류 유형: 829. uwsgi 설치 시 fatal error: Python.h: No such file or directory
13176정성태11/29/20224637오류 유형: 828. gunicorn - ModuleNotFoundError: No module named 'flask'
13175정성태11/29/20226471오류 유형: 827. Python - ImportError: cannot import name 'html5lib' from 'pip._vendor'
13174정성태11/28/20224909.NET Framework: 2073. C# - VMMap처럼 스택 메모리의 reserve/guard/commit 상태 출력파일 다운로드1
13173정성태11/27/20225682.NET Framework: 2072. 닷넷 응용 프로그램의 스레드 스택 크기 변경
13172정성태11/25/20225396.NET Framework: 2071. 닷넷에서 ESP/RSP 레지스터 값을 구하는 방법파일 다운로드1
... 16  17  [18]  19  20  21  22  23  24  25  26  27  28  29  30  ...