MEF가 적용된 ASP.NET 웹 사이트를 제니퍼 닷넷으로 모니터링 해본 결과!
지인 한 분이, 이번 참에 MEF(Managed Extensibility Framework)를 공부할 겸 간단하게 prototype 형식의 웹 사이트를 하나 만들었다고 하시면서... MEF 적용 자체는 Biz 계층과 Dac 계층에 모두 적용을 했는데, 속도가 너무 안 나와서 Biz만 MEF를 적용하는 것이 나을지, 아니면 Dac 쪽만 MEF를 적용하는 것이 나을 지에 대해서 제게 의견을 구했습니다.
사실 ^^ 저도 MEF는 자료로 보기만 하고 직접 사용해 본적은 없기 때문에 ... 마침 잘 되었다 싶어서 그 분께 관련 테스트 소스를 요청해서 받았습니다. 그런 후 '제니퍼 닷넷'으로 검사해 보았는데요... 이번 글은 그에 대한 결과를 공유하는 차원에서 써 봅니다. ^^
최대한 재현을 잘 해내기 위해 소스 코드를 요청했지만, 비슷한 뼈대의 구성으로 ASP.NET에 MEF를 적용한 예제가 아래의 글에도 공개되어 있으니 이 글을 읽으시는 분들도 쉽게 재현을 할 수 있을 것입니다.
MEF with ASP.NET - "Hello World!"
; http://www.codeproject.com/KB/aspnet/MEFwithASPNET.aspx
소스 코드를 살펴보면 다음과 같은데요.
protected void Page_Load(object sender, EventArgs e)
{
DirectoryCatalog catalog = new DirectoryCatalog(
System.IO.Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "bin"));
CompositionContainer container = new CompositionContainer(catalog);
container.ComposeParts(this);
}
지인이 보내주신 코드도 위의 방법과 크게 다르지 않았습니다.
실행하고 곧바로 default 웹 페이지를 방문했는 데, 과연 다음과 같이 3초 가까운 시간이 흐른 것을 확인할 수 있었습니다.
위의 화면에서 발견할 수 있는 또 다른 문제는 "CPU_T" 열에 있는 2,606ms 수치입니다. 즉, default.aspx 웹 페이지가 응답까지 걸린 시간이 2,789ms가 걸렸는데 그동안 계속해서 CPU가 거의 100% 일을 한 것이나 다름없다는 의미입니다. 보통, 데이터베이스 조회 시에 DB가 무거워서 GAP 시간이 수 초가 넘게 걸려도 웹 서버의 CPU는 50ms 이하로 일을 하는 경우가 대부분이어서 웹 서버 자체는 사실 부하가 심하지 않은 경우가 대부분입니다.
그런데, 위의 경우는 웹 페이지가 방문되는 횟수가 늘어날 수록 CPU는 더욱 심하게 일하게 되어 웹 서버 자체의 운영에 심각한 영향을 줄 수 있음을 보여주는 것입니다.
아쉽게도, 제니퍼 닷넷이 보여주는 '기본 프로파일 정보'에는 DB/WCF/COM+/ASMX/.NET Remoting 이외에는 어떤 부분에서 시간이 걸렸다는 것을 보여주지 않기 때문에 위의 X-View 상세 보기 화면에서는 더 이상의 단서를 발견할 수는 없었습니다.
그래도 ^^ 여기서 이야기가 끝이면 아마 이 글을 쓰지도 않았겠지요.
아직 많은 분들이 모르시지만 ^^ '제니퍼 닷넷'은 사용자 어셈블리의 모든 메서드 호출을 프로파일링 할 수 있는 기능이 추가되어 있습니다. 이 기능을 활성화 하려면 '제니퍼 닷넷 에이전트'가 설치된 폴더의 'profile.ini' 파일에서 제공되는 "application_allmethods" 옵션 값을 "1"로 바꿔주어야 합니다.
[methodprofile]
application_allmethods=1
이렇게 변경하고 웹 사이트를 재생(recycle)해주면 이제 사용자 어셈블리의 (생성자를 제외한) 모든 메서드 호출에 대해서 프로파일링을 남겨줍니다. 아래는 위의 MEF 웹 사이트를 방문했을 때 남겨진 프로파일링 기록입니다.
훨씬 자세해졌지요. ^^ 보시는 것처럼, 전체적인 ASP.NET 웹 페이지의 ProcessRequest 처리에는 3,655ms가 걸렸고 그 이하 Page_Load와 UserControl의 Page_Load에서 각각 1.5초씩 지연된 것을 볼 수 있습니다.
아하... 결국 MEFManager.Compose가 재귀 호출되면서 한 번 호출될 때마다 약 90ms씩 CPU를 사용하면서 지연이 된 것임을 위의 프로파일 결과로 한 눈에 알 수 있습니다.
정리해 보면, 웹 사이트의 'bin' 폴더에는 총 650KB 용량의 DLL 파일들이 놓여 있었고 MEF가 적용된 웹 페이지는 Page_Load 시마다 그 DLL을 모두 로드하고 .NET Reflection으로 Export 특성이 적용된 타입들을 찾아내는 작업을 하고 있는 것이었습니다.
위와 같은 상황을 전달해 드렸더니, 그 분은 MEF가 적용된 DLL을 별도의 폴더로 분리하고 DirectoryCatalog를 그 폴더로 지정해서 속도 향상을 보았다고 합니다.
그런데, 일단 제 의견은 "
(DirectoryCatalog를 쓰는 한) MEF는 ASP.NET에 적용해서는 안된다"입니다. 왜냐하면, 프로젝트가 진행되면서 점점 더 MEF가 적용된 DLL은 늘어갈 것이고 그때 쯤이면 또다시 성능 문제가 불거져 나올 것이기 때문입니다.
(결국,,, 이 글을 통해서 제니퍼 닷넷의 application_allmethods 옵션에 대한 자연스러운 홍보가 된 것 같습니다. ^^)
추가: MEF의 DirectoryCatalog를 cache 해두면 위의 성능 문제를 개선할 수 있습니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]