Microsoft MVP성태의 닷넷 이야기
.NET Framework: 283. MEF를 ASP.NET에 성능 손실 없이 적용하려면? [링크 복사], [링크+제목 복사]
조회: 18175
글쓴 사람
정성태 (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)
13433정성태11/1/20232397스크립트: 61. 파이썬 - 함수 오버로딩 미지원
13432정성태10/31/20232482오류 유형: 878. 탐색기의 WSL 디렉터리 접근 시 "Attempt to access invalid address." 오류 발생
13431정성태10/31/20232806스크립트: 60. 파이썬 - 비동기 FastAPI 앱을 gunicorn으로 호스팅
13430정성태10/30/20232695닷넷: 2153. C# - 사용자가 빌드한 ICU dll 파일을 사용하는 방법
13429정성태10/27/20232976닷넷: 2152. Win32 Interop - C/C++ DLL로부터 이중 포인터 버퍼를 C#으로 받는 예제파일 다운로드1
13428정성태10/25/20233054닷넷: 2151. C# 12 - ref readonly 매개변수
13427정성태10/18/20233251닷넷: 2150. C# 12 - 정적 문맥에서 인스턴스 멤버에 대한 nameof 접근 허용(Allow nameof to always access instance members from static context)
13426정성태10/13/20233410스크립트: 59. 파이썬 - 비동기 호출 함수(run_until_complete, run_in_executor, create_task, run_in_threadpool)
13425정성태10/11/20233197닷넷: 2149. C# - PLinq의 Partitioner<T>를 이용한 사용자 정의 분할파일 다운로드1
13423정성태10/6/20233175스크립트: 58. 파이썬 - async/await 기본 사용법
13422정성태10/5/20233322닷넷: 2148. C# - async 유무에 따른 awaitable 메서드의 병렬 및 예외 처리
13421정성태10/4/20233400닷넷: 2147. C# - 비동기 메서드의 async 예약어 유무에 따른 차이
13420정성태9/26/20235593스크립트: 57. 파이썬 - UnboundLocalError: cannot access local variable '...' where it is not associated with a value
13419정성태9/25/20233223스크립트: 56. 파이썬 - RuntimeError: dictionary changed size during iteration
13418정성태9/25/20233929닷넷: 2146. C# - ConcurrentDictionary 자료 구조의 동기화 방식
13417정성태9/19/20233456닷넷: 2145. C# - 제네릭의 형식 매개변수에 속한 (매개변수를 가진) 생성자를 호출하는 방법
13416정성태9/19/20233259오류 유형: 877. redis-py - MISCONF Redis is configured to save RDB snapshots, ...
13415정성태9/18/20233757닷넷: 2144. C# 12 - 컬렉션 식(Collection Expressions)
13414정성태9/16/20233516디버깅 기술: 193. Windbg - ThreadStatic 필드 값을 조사하는 방법
13413정성태9/14/20233711닷넷: 2143. C# - 시스템 Time Zone 변경 시 이벤트 알림을 받는 방법
13412정성태9/14/20236998닷넷: 2142. C# 12 - 인라인 배열(Inline Arrays) [1]
13411정성태9/12/20233505Windows: 252. 권한 상승 전/후 따로 관리되는 공유 네트워크 드라이브 정보
13410정성태9/11/20235033닷넷: 2141. C# 12 - Interceptor (컴파일 시에 메서드 호출 재작성) [1]
13409정성태9/8/20233889닷넷: 2140. C# - Win32 API를 이용한 모니터 전원 끄기
13408정성태9/5/20233846Windows: 251. 임의로 만든 EXE 파일을 포함한 ZIP 파일의 압축을 해제할 때 Windows Defender에 의해 삭제되는 경우
13407정성태9/4/20233590닷넷: 2139. C# - ParallelEnumerable을 이용한 IEnumerable에 대한 병렬 처리
1  2  3  4  5  6  7  [8]  9  10  11  12  13  14  15  ...