Microsoft MVP성태의 닷넷 이야기
.NET Framework: 283. MEF를 ASP.NET에 성능 손실 없이 적용하려면? [링크 복사], [링크+제목 복사],
조회: 18182
글쓴 사람
정성태 (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)
13307정성태4/4/20233908.NET Framework: 2106. C# - .NET Core/5+ 환경의 Windows Forms 응용 프로그램에서 HINSTANCE 구하는 방법
13306정성태4/3/20233702Windows: 243. Win32 - 윈도우(cbWndExtra) 및 윈도우 클래스(cbClsExtra) 저장소 사용 방법
13305정성태4/1/20234072Windows: 242. Win32 - 시간 만료를 갖는 MessageBox 대화창 구현 (쉬운 버전)파일 다운로드1
13304정성태3/31/20234421VS.NET IDE: 181. Visual Studio - C/C++ 프로젝트에 application manifest 적용하는 방법
13303정성태3/30/20233791Windows: 241. 환경 변수 %PATH%에 DLL을 찾는 규칙
13302정성태3/30/20234391Windows: 240. RDP 환경에서 바뀌는 %TEMP% 디렉터리 경로
13301정성태3/29/20234491Windows: 239. C/C++ - Windows 10 Version 1607부터 지원하는 /DEPENDENTLOADFLAG 옵션파일 다운로드1
13300정성태3/28/20234134Windows: 238. Win32 - Modal UI 창에 올바른 Owner(HWND)를 설정해야 하는 이유
13299정성태3/27/20233896Windows: 237. Win32 - 모든 메시지 루프를 탈출하는 WM_QUIT 메시지
13298정성태3/27/20233883Windows: 236. Win32 - MessageBeep 소리가 안 들린다면?
13297정성태3/26/20234558Windows: 235. Win32 - Code Modal과 UI Modal
13296정성태3/25/20233887Windows: 234. IsDialogMessage와 협업하는 WM_GETDLGCODE Win32 메시지 [1]파일 다운로드1
13295정성태3/24/20234163Windows: 233. Win32 - modeless 대화창을 modal처럼 동작하게 만드는 방법파일 다운로드1
13294정성태3/22/20234334.NET Framework: 2105. LargeAddressAware 옵션이 적용된 닷넷 32비트 프로세스의 가용 메모리 - 두 번째
13293정성태3/22/20234396오류 유형: 853. dumpbin - warning LNK4048: Invalid format file; ignored
13292정성태3/21/20234511Windows: 232. C/C++ - 일반 창에도 사용 가능한 IsDialogMessage파일 다운로드1
13291정성태3/20/20234905.NET Framework: 2104. C# Windows Forms - WndProc 재정의와 IMessageFilter 사용 시의 차이점
13290정성태3/19/20234370.NET Framework: 2103. C# - 윈도우에서 기본 제공하는 FindText 대화창 사용법파일 다운로드1
13289정성태3/18/20233567Windows: 231. Win32 - 대화창 템플릿의 2진 리소스를 읽어들여 자식 윈도우를 생성하는 방법파일 다운로드1
13288정성태3/17/20233682Windows: 230. Win32 - 대화창의 DLU 단위를 pixel로 변경하는 방법파일 다운로드1
13287정성태3/16/20233846Windows: 229. Win32 - 대화창 템플릿의 2진 리소스를 읽어들여 윈도우를 직접 띄우는 방법파일 다운로드1
13286정성태3/15/20234287Windows: 228. Win32 - 리소스에 포함된 대화창 Template의 2진 코드 해석 방법
13285정성태3/14/20233868Windows: 227. Win32 C/C++ - Dialog Procedure를 재정의하는 방법파일 다운로드1
13284정성태3/13/20234093Windows: 226. Win32 C/C++ - Dialog에서 값을 반환하는 방법파일 다운로드1
13283정성태3/12/20233644오류 유형: 852. 파이썬 - TypeError: coercing to Unicode: need string or buffer, NoneType found
13282정성태3/12/20233965Linux: 58. WSL - nohup 옵션이 필요한 경우
1  2  3  4  5  6  7  8  9  10  11  12  [13]  14  15  ...