서비스의 성능과 그 상세 내역(프로파일)을 추적하는 것은 서비스 중심 프로파일링이라 하고 Java EE컴포넌트(즉 서블릿, EJB JDBC)단위로 성능과 그 상세내역(프로파일)을 추적하는것을 컴포넌트 중심 프로파일링이라 한다.
Service Base Profiling
서비스의 처리 로직을 상세하게 추적한다. 모든 프로파일 정보를 서비스 단위로 맵핑한다.서비스 단위로 프로파일 정보를 확인할 수 있다.
Component Base Profiling
프로파일 정보를 컴포넌트 단위로 수집한다. 따라서 프로파일 정보를 컴포넌트 단위로 확인할 수있다. 만약 서비스에 대한 프로파일 검토가 필요하면 서비스가 호출한 컴포넌트를 확인하고 이 컴포넌트의 프로파일을 확인한다.
※컴포넌트 기반 프로파일링의 문제
컴포넌트 기반의 프로파일링은 얼핏 보면 논리적이고 서비스 기반 프로파일링 보다 자세한정보를 보여줄 것 같다. 하지만 컴포넌트 기반 프로파일링은 컴포넌트의 특성 때문에 비효율적인 서비스 모니터링 방법이다.
컴포넌트의 수행시간의 대부분은 여전히 JDBC혹은 TP와 같은 외부 호출이다.
컴포넌트 기반의 프로파일링의 이유의 핵심은 성능 저하 원인을 SQL이나 TP호출 보다는 어떤 Java EE컴포넌트에서 기인할 것이라는 가정하기 때문이다.
하지만 실제 프로덕션 환경에서 성능저하의 원인인 대부분 외부 시스템 즉 SQL/TP/LDAP호출에서 기인하는 경우가 더 많다..
그래서 컴포넌트 중심 프로파일링을 하게되면 컴포넌트 단위의 프로파일을 보고 그것이 서비스에 어떻게 영향을 미쳤는지를 알기 위해서는 다시 서비스 프로파일을 보아야 한다. 즉 서비스->컴포넌트, 다시 컴포넌트->SQL/TP의 2중의 프로파일을 분석해야 한다.
서비스와 컴포넌트간의 맵핑을 해야하고 서비스와 SQL/TP 간의 맵핑은 어렵다.
컴포넌트는 서비스와 N:M관계이다 또한 컴포넌트와 SQL/TP관계도 N:M관계이다. 그리고 컴포넌트간의 호출관계도 발생한다 그만큼 그들간의 맵핑 정보는 복잡해지고 추적과 분석이 어려워 진다.
운영 담당자는 컴포넌트를 잘 모른다
어쩌면 이것이 가장 큰 문제 일수있다. 일반적으로 운영담당자는 Java EE의 전문가가 아니다. 개략적인 이해만 있을 뿐이다. 설령 JavaEE에 지식이 풍부하더라도 운영담당자가 개발에 참여하는 경우는 거의 없다. 당연히 운영 담당자는 애플리케이션 내의 컴포넌트 구성이나 상관관계에 대한 깊은 이해가 어렵다. 또한 이들에게는 Application Server Tier의 진입점인 서비스 로부터 끝지점인 DB/TP 연계 중심으로 성능을 이해하는 것이, EJB나 Servlet/JSP, JMS 등과 같은 컴포넌트 구성을 이해하는 것이 보다는 쉽다.
당연히 이들은 느린 서비스를 추출하고 그것의 수행내역을 개발자에게 검토 요청하는 것이가장 효과적일 것이다.
오버헤드를 피할 수 없다.
애플리케이션 서비스를 프로파일링해 보면 프로파일링 자체의 오버헤드도 있지만, 프로파일링정보의 목록을 관리하는 오버헤드도 크다. 그런데 컴포넌트 단위의 프로파일링에서는 각 컴포넌트 별로 프로파일링 목록을 관리해야 하기 때문에 프로파일링 목록이 엄청나게 많아진다.
그렇다고 프로파일링 컴포넌트를 필터링하게되면 분석정보의 유실이나 왜곡을 피할 수 없다.
