반응형


뇌운동 방법입니다.

아래 참고하시고 건강한 뇌 되세요!!

 

1. 아침 밥을 꼭 먹도록 해라

 뇌는 에너지를 저장하는 곳이 없고, 포도당의 농도가 맞지 않으면 급격하게 움직임이 떨어지고 포도당이 흡수되지 않으면 이내 사멸해 버린다. 2~3일 굶으면 혈중의 당이 제일 먼저 뇌로 공급되도록 되는 것을 보아 뇌가 가장 중요함을 몸도 알고 있다는 것이다. 입으로 씹는 행위는 움직이는 근육운동으로 인해 뇌를 자극하여 더욱 활성화시키게 된다. 단기 기억을 요하는 행동을 하기 전에 껌이나 무엇을 씹으면 그 기억능력이 향상된다는 말도 같은 이유인 것 같다.


2. 어디서나 숫자를 세고, 계산한다.

 뇌는 숫자를 매우 좋아한다고 할 정도로 숫자를 셀 때 뇌의 많은 부위가 적극적으로 활성화되는 것을 볼 수 있다. 심심할 때, 목욕탕에 들어가 있을 때 1~100까지 센다거나 바로 앞에 보이는 차의 번호판을 더하거나 곱하여 계산하면서 뇌를 활성화할 수 있다.


더욱이 단순히 숫자를 세는 것이 아니라 걸음을 걸으며 그 걸음을 숫자로 소리 내어 세면서 지나치는 지점의 숫자가 무엇이었는지 기억하는 것을 일정한 게임으로 하면 다양한 기능을 담당하는 뇌의 각 부분이 활성화됨을 알 수 있다.


※단순한 숫자를 단시간 집중해서 계산할 때는 좌우의 전두엽이 점점 활성화되지만 익숙하지 않은 복잡한 계산 문제를 풀 때는 좌뇌만 움직이고 우뇌는 움직임이 별로 없다.

특히 이 책 전체에서는 단순한 숫자를 계산하는 것을 매우 중요하게 언급하고 반복하고 있다. 특히 창의력을 위해서는 숫자와 문장의 낭독 등 말을 하는 것을 중요하게 여긴다. 이는 실험결과 창의력을 발휘할 때 움직이는 뇌의 영역이 읽기와 계산을 할 때 활성화됨을 알았기 때문이다. 


3. 정기적으로 눈에 보이는 문장을 낭독하거나 묵독한다.

 글씨를 읽는 것 만으로도, 사물을 볼 때나, 숫자 또는 그림의 의미를 해석할 때, 언어의 의미를 해석할 때, 소리를 듣고 해석할 때는 특히 뇌의 많은 부분이 활발하게 움직인다고 한다. 그래서 낭독을 하거나, 예전의 천자문을 암송하며 공부하는 것은 뇌를 활성화하는 좋은 예라고할 수 있다. 단지 단 5분을 하더라도 정기적으로 하는 것이 중요하지만 이것이 어려운 일이 아닌가 싶다.


4. 사람의 얼굴이나 현재의 표정으로 유추해 보라
사람의 얼굴을 유심히 보는 것만으로도 사물을 볼 때 움직이는 뇌의 부분이 활성화된다. 하지만 이를 기준으로 ‘연상’을 하게 되면 뇌의 여러 영역이 동시에 활성화 됨을 알 수 있다. 사람의 얼굴 표정을 보고 그 사람의 기분과 이전의 스토리를 상상한다거나 사람의 얼굴을 보고 그 사람에 맞는 옷이나 속옷을 상상하는 등을 예로 들 수 있다. 이런 것은 많은 놀이와 축제에서 행해지고 있는 일이다.
 

5. 오른손 잡이는 왼손을 사용하면 좌우 뇌가 동시에 활성화 한다.
 오른손 잡이가 오른손을 사용하면 왼쪽 뇌가 활성화되지만 오른손 잡이가 잘 쓰지 않는 왼손을 사용하게 되면 명령에 익숙하지 않은 우뇌가 익숙한 좌뇌의 도움을 받아 움직인다. 그렇기 때문에 잘 사용하지 않는 쪽의 손이나 육체의 움직임을 활성화 시키는 것이 뇌 전체를 활성화하는데 좋은 방법이 될 수 있다.
 

6. 집중력은 뇌활동의 효율성을 극도로 높인다.
 집중력이 창의력과 무슨 관계인가? 뇌는 두 가지를 동시에 하면 혼란스러워 한다. 손가락으로 주머니 안의 동전을 만져 촉감만으로 동전의 앞뒤를 구분하는데 집중하다 보면 <사물의 감촉을 판별하는 체성감각야>와 <물체의 위치와 방향을 알아내는 두정연합야>를 단련시키지만 후두엽의 <사물을 바라볼 때 작용하는 시각야>와 측두엽의 <사물의 정체를 파악하는 하측두회>의 활동이 감소한다. 뇌는 하나에 집중하게 되면 다른 영역의 활동을 억제하는 경향이 있어 감촉에 집중하기 위해서 시각으로 들어오는 정보를 막기 위해 눈을 감는 활동을 하게 된다. 한편으로 억제한다는 말은 한편으로 한 쪽의 효율성을 극대화한다는 말이다.
 

여기에서는 집중의 조건을 뇌 활동의 효율성으로 이야기하지만 창의력에서는 집중할 수 있는 능력을 중요한 창의력 발전의 중요한 전제 조건으로 이야기 하곤 한다. 하기야 뇌 기능이 저하되면 제일 먼저 집중력이 없어지고 감정을 억제하지 못하는 현상이 나타나는 것을 보면 집중력은 뇌가 정상적이고 효율적으로 작동되고 있다는 증거가 되기도 하니까 맞는 말인 것 같다.
 

7. 해야할 일의 우선순위를 정하는 것은 뇌를 활성화 한다.
 일의 우선순위를 정하고 이를 처리하는 이미지를 그려보는 것만으로도 뇌를 활성화할 뿐만 아니라 일을 체계적이고 빠르게 수행할 수 있다. 뿐만 아니라 일의 우선순위를 정하는 것 자체는 자신의 가치관을 기준으로 우선순위를 따져 복잡한 상황에 규칙성을 부여하여 이를 순서대로 나열하다 보면 전두엽의 활성화가 일어난다.
<그렇기 때문에 가족 주간회의를 통해 자신의 주간 일정을 정해서 발표하는 활동을 통해 뇌를 다각적으로 활성화할 수 있다. 이는 사람들의 표정과 시선을 함께하면서 사람들의 의사, 감정, 사고를 고려하면서 내용을 전달하는 커뮤니케이션은 전두엽의 활동을 또한 촉진하기 때문이다>
 
 
 
8. 오늘 만난 사람의 이름을 기억하려고 한다.
뇌는 기억하려고 할 때 활성화된다. 사람의 뇌는 단순히 생각을 떠 올리는 것 보다는 기억하려고 할 때 뇌(전두전야)가 본격적으로 움직이기 시작한다. 단순히 떠 올리는 것이 아니라 기억하려고 시작할 때 기억이 정착된다는 말이다. 사람의 이름을 부르면 청각과 더불어 시각을 담당하는 뇌가 활성화된다. 그기에 기억하려는 의도의 시작은 기억과 관련된 뇌을 움직이게 하기 때문에 휠씬 더 잘 기억하게 된다.

기억력이 좋다는 말은 기억과 연관된 것이 맡아 쉽게 의식으로 꺼집어 올린다는 말이다.
기억력을 좋게 하기 위해서는 뇌에 기록된 정보의 연관된 체인이 많다는 것이다. 연관된 체인이 많게 기억하고 있으면 이를 쉽게 꺼집어 낼 수 있다는 것이고 이를 두고 기억력이 좋다는 것이다. 결국 뇌에 연관된 체인이 많도록 훈련되어 있으면 의식의 얕은 곳까지 걸려들기 쉬운 곳까지 기억이 올라와 쉽게 꺼집어 낼 수 있도록 되어 있다는 것이다. 쓰면 쓸수록 그 능력이 향상되는 뇌에 지속적으로 연관된 체인을 만들기 위해서 궁리해야 한다는 것이다.

자기 전에는 정신을 평화롭고 자유롭게 하라는 사람도 있지만 나의 경우는 잠자리에 누워서 오늘 만난 사람들을 순서대로 만나서 나눈 이야기의 이슈를 기억해 본다. 그것이 완료되면 마음은 한결 편해진다. 그러면 그런 종료의 기분 때문에 그런지 잠이 잘 오기도 한다.
 
9. 매일 새로운 패턴의 운용으로 뇌를 새롭게 자극준다.
 창의력을 연구하다 보면 뇌는 같은 것, 패턴화되는 것을 싫어한다는 이야기를 많이 듣는다. 같은 작업만 반복하고 패턴화되어 있으면 뇌의 기능은 저하된다. 뇌에 가장 좋지 않은 행동은 같은 행동을 반복하는 것이다. 왜냐하면 뇌만큼 실증을 잘 내고 새로운 자극을 좋은하는 존재도 없기 때문이다. 그래서 매일 새로운 점심 메뉴를 찾거나 출퇴근 시간, 교통수단, 노선의 변경은 그 만큼 뇌에 새로운을 줄 수 있는 뇌를 활성화시키는 일상 패턴이자 좋은 방법이 된다.
 

10. 완성을 연상하며 조립하거나 그리거나 자르는 즐거운 놀이를 만든다
아직 완성되지 않은 상태에서 결과를 연상하면서 만드는 종이 접기나 그림 그리기, 조각, 요리, 무늬 오리기는 뇌(전두전야)를 활성활 할 뿐만 아니라 창의력과 집중력을 증강시킨다. 이런 것을 할 때 마음을 담은 동기가 있어 즐기는 것은 뚜렷한 목표와 기준이 있기 때문에  뇌의 활성화를 더욱 촉진시킨다. 그렇지 않은 상태에서 뇌는 전혀 다르게 움직이기 때문이다.
 

11. 눈에 띄는 사물의 명칭으로 동사형을 연상해 본다.
창의력을 할 때도 흔하게 언급되는 것이지만 특정 주제나 단어를 던지고 관련된 말이나 언어, 이미지를 쓰라고 하면 당장 몇 개도 연상해 내기 어렵다. 연상은 뇌의 활동을 촉진하는 좋은 방법이다. 이 말은 뇌의 혈류 속도를 원활하게 자극한다는 말이다. 또한 뇌에 기록된 정보들간의 연관된 체인을 많이 만들어 더 많이 기억하고 쉽게 기억을 꺼집어 올릴 수 있는 조건을 만든다는 말이다. 연필=> 깍다. 부러지다. 굴러가다, 쓰다..../ 개=>짖다, 물다, 먹다, 꼬리치다...이를 소리를 내어 이야기하면 다각적으로 뇌를 활성화할 뿐만 아니라 창의력도 높아진다. 또는 연속된 그림을 제시하고 그 다음은 어떤 그림이 나올지를 연상하거나 / 특정 사건에 대한 변신 로봇이 무엇으로 변신할 지에 대한 연상활동이 좋은 훈련방법이 될 수 있다.
 

12. 뇌를 많이 사용했을 때 TV시청으로 쉬게 한다.
뇌의 건강 차원에서 혹사당한 뇌를 쉬게하고 다시 활동하도록 하면 더욱 활발하게 뇌를 활용할 수 있다. 이때 뇌를 쉬게 하는 방법으로 TV를 시청하면 좋다. 실험을 통해 TV를 시청할 때는 뇌(전두전야)의 혈류 속도가 떨어지는데 이는 가만히 눈을 감고 아무것도 하지 않을 때 보다 더 둔해지고 활동을 멈춘다는 것이다. 이런 사실은 개인적으로 매우 놀라운 사실인데 TV를 너무 많이 봐서 머리가 항상 멍하고 순발력이 늦은 것은 아닌지 의심 스럽다.
 

13. 좋아하는 시, 영화나 드라마 대사을 주기적으로 낭송한다.
 소리내어 낭송한다는 것은 비단 그 뜻을 몰라도 간단한 계산을 빠르게 하는 것만큼이나 뇌의 많은 영역을 동시에 활성화 시켜 준다. 반복적이고 꾸준한 낭독은 직접적으로 관련이 없는 기억력까지도 향상시킨다는 것을 실험을 통해 확인할 수 있었다고 한다. 나의 경우에는 내가 좋아하는 영화나 드라마의 대사를 암기하면 좋겠다 싶다. 대사를 암기하는 훈련과 낭독을 하며 그 장면을 동시에 연상하면서 이어 나의 일상과 연관지어 생각해 볼 수 있기 때문이다. 

반응형
commons-logging-1.1.1.jar    //로그 출력
http://commons.apache.org/downloads/download_logging.cgi
mp3spi1.9.4.jar                    //MpegAudioSPI1.9.4  mp3 재생
http://www.javazoom.net/mp3spi/mp3spi.html
vorbisspi1.0.3.jar                 //OGG
http://www.javazoom.net/vorbisspi/vorbisspi.html
jl1.0.jar
http://www.javazoom.net/javalayer/javalayer.html
tritonus_share-0.3.6.jar
http://tritonus.org/
등의 라이브러리가 필요하다

관련자료와 링크는 이전 포스트에 있다
http://www.pmguda.com/448
반응형

<FreeMind>

FreeMind 는 마인드맵 프로그램 입니다. 타 프로그램과 차이점은 "무료"라는 점 입니다.

FreeMind 는 한글메뉴를 지원 합니다. 이 프로그램은 자바로 만든 프로그램이라

맥킨토시등 다양한 시스템과 호환이 됩니다. 

 설치순서

1. 자바프로그램을 컴퓨터에 깝니다.

2. 프로그램을 깝니다.

3. 프로그램을 실행 시킨후 메뉴 Tool 들어가시면 언어를 "kr"로 바꾸시면 한글메뉴로 변화 합니다.

4. 마인드맵을 작성하는데 다양한 이미지 파일이 필요하시다면 "이미지파일"을 다운로드 하시면 됩니다.

 자바프로그램

http://ftp5.ohpy.com/up/elbbs/2007/02/15/26350/1171502511/jre-1_5_0_10-windows-i586-p-s.exe

프로그램(0.9.0 BATA15 최신버젼)

http://nchc.dl.sourceforge.net/sourceforge/freemind/FreeMind-Windows-Installer-0_9_0-Beta15.exe

 이미지파일

http://nchc.dl.sourceforge.net/sourceforge/freemind/freemind-bin-max-0.9.0_Beta_15_icon_butterfly.zip

 <컨셉리더>

 1. 프로그램을 다운로드 합니다.

2. 개인에 한에 무료로 라이센스키를 보내드립니다. 사이트에 회원 가입 하신후에

    라이센스 요청 하시면 됩니다.

프로그램
http://www.conceptleader.com/files/program/CCLinstall_ko.exe

 무료라이센스키 받기 (회원가입 해야함)http://www.conceptleader.com/conceptleadercokr/index.asp?page=keydown

 

반응형

"당신의 열정을, 실제 일을 성공시키는데 쓰기보다, 사람들을 설득하는데 더 많이 쓰게 되는 불상사를 방지하기 위한 것이다." - 끝내주는(great) 팀이 필요한 진짜 이유 [김기웅]



출처는 김기웅님의 블로그  http://betterways.tistory.com/295 
반응형

책 소개
그대 개발자여, 자신을 다시 점검하라!

소프트웨어 개발자로 밥벌이를 하고 있지만 알게 모르게 우리의 일자리는 줄어들고 있다. 회사도 변하고, 기술도 변하고, 경제도 변하고 있다. 뿐만 아니라, 가치를 어떻게 창출해야하는지 그 방법도 변하고 있다. 여기서 우리는 이러한 변화에 어떻게 대처해야 할까? 만약 올바르게 대처하지 못한다면 어떤 위험이 닥칠까?

IT 경기가 불황으로 돌아서고 일자리는 차츰 줄어들고 기술의 변화는 한시도 멈추지 않는다. 이것은 분명 우리에게는 위협적인 상황이다. 차드 파울러는 이렇게 예측 불가능한 시장 상황에 올바르게 대처하는 방법을 52가지의 이야기로 우리에게 제시하고 있을 뿐만 아니라 궁극적으로 소프트웨어 개발자로 살아가는 올바른 길을 보여주고 있다. 이 책에서 제시하는 주요 내용은 다음과 같다.

1.올바르게 선택하라.
집중해야 할 기술과 섭렵해야 할 비즈니스 분야를 선택하는 문제는 공학적 지식을 쌓는 것만큼이나 자신의 성공과 직결되는 문제이다. 절대 우연히 또는 아무 생각 없이 선택하지 말라. 이 책에서는 올바르게 선택하기 위한 관점을 제시할 뿐만 아니라 자신의 한정된 시간과 에너지를 어느 분야에 효과적으로 투자해야 할지에 대해 확신을 주고 있다.

2.많은 기술을 수련하라.
멀게는 무섭게 진출하는 저임금 국가의 개발자뿐만 아니라 가깝게는 개발자 시장에서 소위 잘 나가는 동료 개발자들과 경쟁하기 위해서 무엇이 시급히 필요한가? 아마 자신의 기술을 수련하고 업데이트하기 위한 체계적인 계획이 필요할 것이다. 이 책은 개발자 가치 생태계에서 살아남기 위해 자신의 기술을 어떻게 수련할 것인가에 대해 알려주고 있다.

3.자신을 적극적으로 마케팅 하라.
제품이나 서비스나, 알리지 않고서는 사는 사람이 아마 없을 것이다. 이 책에서는 IT 산업 현장에서 또는 회사에서 자신을 어떻게 마케팅 할 것인지 알려주고 있다.


IBM DW에서 열린 '개발자들의 수다'에서 만나 이야기를 나눈 김기웅님이 추천해주신 책이다.

개발자로서의 길을 걷는 내게 무언가 자극이 되고 나의 열정을 불태우는 계기가 되기를 바라고

집에 돌아오자 마자 바로 질러버렸다.

어제 택배를 받고 오늘 아침 출근길에 조금 읽어 보았다. 아직 다 읽어보진 않았지만..

출퇴근길의 짜투리 시간에 틈틈히 읽을 생각이다. 이 책의 감상평도 다 읽고 난 다음으로..^^

/*  ===========================================================================
*    사랑하지 않으면 떠나라.     2009.03.25
*   ============================================================================ */
사랑하지 않으면 떠나라.

사랑하지 않으면 떠나라.. 언뜻 보기에 제목이 연애소설 같다..

하지만 프로그래머를 동경하던 내게 프로그래밍은 연애의 감정과도 같을지도 모르겠다.

뭐 이건 제목에 대한 느낌이다. 책을 한번 쭈욱 읽으면서 많은 생각을 하게 되었다.

내가 하고 싶어했던 프로그래머라는 일을 직업으로 택하면서 현재의 일에 대해도 생각하였고

내게 부족한 것들도 알게 되었고 모르는 것들도 깨닫는 기회가 된듯하다.

사람들에게 이 책에 대한 홍보를 참 많이 했던거 같다. 일단 읽어보시길..

이렇게 짧게 쓰다보니 후기라고 할것도 없다. 사실 읽고 난지 좀 시간이 많이 지나서

블로그를 훑어보다가 아참! 후기 써야지 하고 뒤늦게 작성하다 보니... ㅎㅎ;

다시 한번 읽어봐야겠다..^^
반응형


책 소개
퍼즐과 추리 소설로 즐기는 두되 단련하기

퍼즐을 풀기 위해서는 모든 가능성을 고려하는 개방적인 자세로 출발해서 최종 해답을 찾을 때까지 포기하지 않고 밀고 나가는 사고방식이 필요하다. 프로그래밍 취업 면접을 준비하는 사람들과 단지 퍼즐을 즐기는 사람들 모두를 위해 만들어진 이 책은 문제 해결 과정을 단계적으로 밟아 나가면서 독자의 퍼즐 해결 능력을 극적으로 향상시켜 준다. 이 책에서 여러분은 스도쿠 같은 간단한 소거 문제를 해결하는 방법은 물론, 그보다 훨씬 더 어려운 문제들에 발견법적 기법을 적용하는 방법도 배울 수 있다.

Dr. 샤샤가 쓴 이 책은 일정 수립, 전략, 기하, 확률 퍼즐 등 다양한 부류의 퍼즐들을 손으로, 그리고 컴퓨터로 풀기 위한 수단과 도구를 제시한다. 또한 암호, 은행 계좌, 지리에 관한 퍼즐들로 가득 찬 미스테리 단편도 수록되어 있다. 이 책에 나오는 접근방식과 기법들을 익힌다면 가상의 인위적인 퍼즐뿐만 아니라 현실 업무에서 마주치는 실질적인 문제들도 효과적으로 해결할 수 있을 것이다.


사랑하지 않으면 떠나라! 책을 사면서 도서 상품권이 한장 더 남아 충동적으로 구매한 책.
두뇌단련이 조금 되지 않을까 하는 생각에 무턱대고 질러버렸다.
아무래도 충동구매를 하는걸 보니 두뇌단련이 필요하긴 한거 같다. 이책이 도움이 될까?
흠.. 므튼 틈틈히 풀어봐야겠다.
반응형

개발 도구

  1. Eclipse : http://www.eclipse.org/
  2. Netbean : http://www.netbeans.org/community/releases/60/index.html
  3. Firebug : http://www.getfirebug.com/

소스코드 관리

  1. CVS : http://www.cvshome.org
  2. Subversion : http://subversion.tigris.org
  3. MS Visual SourceSafe
  4. BitKeeper : http://www.bitkeeper.com
  5. ClearCase : http://www-306.ibm.com/software/awdtools/clearcase/

빌드 스크립트 도구

  1. make : http://source.redhat.com/cygwin
  2. Automake : http://www.gnu.org/software/automake
  3. Ant : http://ant.apache.org
  4. NAnt : http://nant.sourceforge.net
  5. Groovy : http://groovy.codehaus.org
  6. Rake : http://rake.rubyforge.org/  
  7. SCons : http://www.scons.org/

빌드 시스템

  1. Mavenhttp://maven.apache.org 
  2. Maven2 : http://maven.apache.org/maven2/index.html

CI 도구 (Continuous integration )

  1. CruiseControl : http://cruisecontrol.sourceforge.net
  2. CruiseControl .NET : http://sourceforge.net/projects/ccnet
  3. DamageControl : http://damagecontrol.codehaus.org
  4. AntHill : http://www.urbancode.com/projects/anthill
  5. Continuum : http://maven.apache.org/continuum
  6. LuntBuild : http://luntbuild.javaforge.com/  
  7. Buildix : http://buildix.thoughtworks.com/  
  8. Hudson : https://hudson.dev.java.net/  (직관적이고 사용법이 쉬움)

이슈 추적 도구

  1. Bugzilla : http://www.bugzilla.org
  2. JIRA : http://www.atlassian.com/software/jira/default.jsp
  3. FogBugz : http://www.fogcreek.com/FogBugz
  4. PR-Tracker : http://www.prtracker.com  
  5. Trac : http://trac.edgewall.org/

테스트 프레임워크

  1. JUnit : http://www.junit.org
  2. NUnit : http://www.nunit.org
  3. xUnit.NET : http://www.codeplex.com/xunit
  4. MbUnit : http://www.mbunit.org
  5. HTMLUnit : http://htmlunit.sourceforge.net
  6. HTTPUnit : http://httpunit.sourceforge.net
  7. JWebUnit : http://jwebunit.sourceforge.net
  8. Cobertura : http://cobertura.sourceforge.net
  9. Clover : http://www.cenqua.com/clover  
  10. Cactus : http://jakarta.apache.org/cactus/
  11. Emma : http://emma.sourceforge.net/
  12. Fit : http://fit.c2.com
  13. Fitness : http://fitnesse.org  
  14. Watir : http://wtr.rubyforge.org
  15. Systir : http://atomicobject.com/systir.page
  16. AUT : http://aut.tigris.org/
  17. UnitTest++ : http://unittest-cpp.sourceforge.net/  
  18. TestNG : http://testng.org/doc/  
  19. CppUnit : http://sourceforge.net/projects/cppunit  
  20. CppUnit2 : http://cppunit.sourceforge.net/cppunit-wiki/CppUnit2  
  21. Selenium : http://www.openqa.org/
  22. Agitar : http://www.agitar.com/  
  23. JTest : http://www.parasoft.com/jsp/home.jsp  
  24. PushToSoft : http://www.pushtotest.com/  
  25. Eclemma : http://www.eclemma.org/

프로젝트 관리

  1. OpenProj : http://openproj.org/openproj 
  2. dotproject : http://www.dotproject.net/
  3. Mantis : http://www.mantisbt.org/

커뮤니케이션 도구, 위키

  1. MoinMoin : http://moinmoin.wikiwikiweb.de/
  2. Confluence : http://www.atlassian.com/software/confluence/
  3. TWiki : http://twiki.org/
  4. SocialText : http://www.socialtext.com/  
  5. Springnote : http://www.springnote.com/ko

성능분석

  1. ANTS Load : http://www.red-gate.com/products/ants_load/index.htm  
  2. JunitPerf : http://www.clarkware.com/software/JUnitPerf.html  
  3. Jmeter : http://jakarta.apache.org/jmeter/

기타

  1. Structure101 : http://www.headwaysoftware.com/index.php  
  2. FreeMind : http://freemind.sourceforge.net/wiki/index.php/Main_Page  
  3. Capistrano : http://manuals.rubyonrails.com/read/book/17
출처 :   개발이 좋아 개발자가된 많은 사람들에게 말하고 싶은 이야기. by k16wire
반응형
당연히 가장 먼저 할 일은 JCL 라이브러리를 받는 것이다. 아파치 다운로드 페이지로 간다.
 
현재 최신 버전은 1.0.4 (2004년 11월 8일 기준)
 
주요 클래스(인터페이스)를 살펴 보면 딸랑 두개다. 로깅을 담당하는 인터페이스인 Log와 Log 인스턴스를 만들어내는 팩토리 클래스인 LogFactory.
 
물론, JCL은 단지 API 역할만 하기 때문에 Log 인터페이스를 상속한 Log 객체를 쓰게 될 것이다.
 
JCL에서 지원하는 로그 수위는 Log4J와 JDK의 중간인 6단계다.
  1. trace (the least serious)
  2. debug
  3. info
  4. warn
  5. error
  6. fatal (the most serious)
실제 로깅을 수행할 때, 초보자가 가장 어려운 부분은 설정일 것이고, 그 후에는 효율적인 로깅을 할 수 있는 노하우나 절차를 익히는 것이다. 설정에 대해 배워보자.
 
JCL을 사용하는 이점 중에 하나는 JCL에 대해서는 설정할 것이 없다는 점이다. 다만, 구현체로 Log4J나 JDK 로깅을 쓰기 위해 이를 위한 설정만 해주면 된다. 어떻게 이것이 가능할까? 물론, JCL에서 이러한 작업을 수행하기 때문에 가능한 것이다. JCL에 포함된 LogFactoryImpl 클래스의 아래와 같은 코드가 이러한 매직을 만드는 것이다.
 
최대한 개발자의 편의를 위해서 commons-logging.properties 파일에 사용하게될 구현체를 설정하지 않으면, 아래 분기문을 수행하면서 Log4J가 사용 가능한지, JDK1.4가 사용 가능한지, Lumberjack 로깅이 사용 가능한지를 순서대로 살펴본다. 따라서, Log4J, JDK 1.4 로깅을 사용할 경우는 JCL에 대한 별도 설정이 필요없다. 여기서 JDK 1.4 기반에서 Log4J를 사용한다면, Log4J가 사용될 것이라는 점을 짐작할 수 있다. 먼저 logClassName이 설정되고 나면, 이후의 if문에서는 선행조건인 (logClassName == null)에서 걸리기 때문이다.
 
 
        if ((logClassName == null) && isLog4JAvailable()) {
            logClassName = "org.apache.commons.logging.impl.Log4JLogger";
        }
        if ((logClassName == null) && isJdk14Available()) {
            logClassName = "org.apache.commons.logging.impl.Jdk14Logger";
        }
        if ((logClassName == null) && isJdk13LumberjackAvailable()) {
            logClassName = "org.apache.commons.logging.impl.Jdk13LumberjackLogger";
        }
        if (logClassName == null) {
            logClassName = "org.apache.commons.logging.impl.SimpleLog";
        }
        return (logClassName);
 
 
아래와 같이 로그 문장 하나를 만들어보자.
 
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

/**
 *
 * @author 안영회
 * @since 2004. 11. 8
 */
public class CommonsLoggerExample {
    private static final Log logger
     = LogFactory.getLog(CommonsLoggerExample.class.getName());

   
    public static void main(String[] args) {
       
        logger.info("hello, log");
       
    }
}
 
아래와 같은 출력문을 만날 수 있다. JDK 1.4 이상을 사용했고, Log4J를 설치하지 않았기 때문이다.
 
2004. 11. 8 오후 2:29:46 CommonsLoggerExample main
정보: hello, log
 
출력 형식과 어디에 출력할 것인가는 어떻게 결정된 것일까? JDK 설치 디렉토리 하위의 JRE/lib 디렉토리에서 logging.properties 파일을 찾을 수 있다. 여기서 JDK 로깅 관련 설정을 하게 된다.
 
############################################################
#   Default Logging Configuration File
#
# You can use a different file by specifying a filename
# with the java.util.logging.config.file system property. 
# For example java -Djava.util.logging.config.file=myfile
############################################################
############################################################
#   Global properties
############################################################
# "handlers" specifies a comma separated list of log Handler
# classes.  These handlers will be installed during VM startup.
# Note that these classes must be on the system classpath.
# By default we only configure a ConsoleHandler, which will only
# show messages at the INFO and above levels.
handlers= java.util.logging.ConsoleHandler
# To also add the FileHandler, use the following line instead.
#handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
# Default global logging level.
# This specifies which kinds of events are logged across
# all loggers.  For any given facility this global level
# can be overriden by a facility specific level
# Note that the ConsoleHandler also has a separate level
# setting to limit messages printed to the console.
.level= INFO
############################################################
# Handler specific properties.
# Describes specific configuration info for Handlers.
############################################################
# default file output is in user's home directory.
java.util.logging.FileHandler.pattern = %h/java%u.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter
# Limit the message that are printed on the console to INFO and above.
java.util.logging.ConsoleHandler.level = INFO
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter

############################################################
# Facility specific properties.
# Provides extra control for each logger.
############################################################
# For example, set the com.xyz.foo logger to only log SEVERE
# messages:
com.xyz.foo.level = SEVERE
logging.properties 파일의 내용이다. 천천히 살펴보자.

#   Default Logging Configuration File
#
# You can use a different file by specifying a filename
# with the java.util.logging.config.file system property. 
# For example java -Djava.util.logging.config.file=myfile
 
디폴트 로깅 설정 파일이라는 것이고, -D 옵션을 넣어서 실행하여, java.util.logging.config.file 프로퍼티를 키로 설정 파일을 다른 것으로 지정할 수 있다는 것이다.

#   Global properties
# "handlers" specifies a comma separated list of log Handler
# classes.  These handlers will be installed during VM startup.
# Note that these classes must be on the system classpath.
# By default we only configure a ConsoleHandler, which will only
# show messages at the INFO and above levels.
handlers= java.util.logging.ConsoleHandler
# To also add the FileHandler, use the following line instead.
#handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
 
전역 설정. 즉, 로깅 전체에 영향을 미치는 설정을 나타낸다. handlers 프로퍼티는 로그 Handler 클래스 설정에 사용되는데, 로그 핸들러(log handler)가 여러 개인 경우에는 콤마로 구분하여 나열한다. 로그 핸들러 클래스는 당연히 클래스패스에 위치해야 하고, 디폴트는 INFO 이상의 로그 수위만 화면에 출력하는 ConsoleHandler이다.
 
# Default global logging level.
# This specifies which kinds of events are logged across
# all loggers.  For any given facility this global level
# can be overriden by a facility specific level
# Note that the ConsoleHandler also has a separate level
# setting to limit messages printed to the console.
.level= INFO
 
모든 로거에 기본적으로 적용할 로그 수위는 INFO라는 것이다.
 
############################################################
# Handler specific properties.
# Describes specific configuration info for Handlers.
############################################################
# default file output is in user's home directory.
java.util.logging.FileHandler.pattern = %h/java%u.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter
# Limit the message that are printed on the console to INFO and above.
java.util.logging.ConsoleHandler.level = INFO
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
 
특정 핸들러에만 적용시킬 프로퍼티. 자세한 내용은 파일 로거를 쓰면서 확인해보자.

############################################################
# Facility specific properties.
# Provides extra control for each logger.
############################################################
# For example, set the com.xyz.foo logger to only log SEVERE
# messages:
com.xyz.foo.level = SEVERE
특정 퍼시리티에만 적용시킬 프로퍼티, 핸드러별 설정보다 더 미세하게 특정 로거단위로도 설정이 가능하다.
 
# show messages at the INFO and above levels.
handlers= java.util.logging.ConsoleHandler
# To also add the FileHandler, use the following line instead.
#handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
 
위와 같은 설정을 아래처럼 바꿔서 파일 로그 핸들러도 쓰이도록 해보자.
 
# show messages at the INFO and above levels.
# handlers= java.util.logging.ConsoleHandler
# To also add the FileHandler, use the following line instead.
handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
 
어디에 출력이 되었을까? 힌트는 logging.properties 파일의 파일 핸들러 관련 설정이다.
 
# default file output is in user's home directory.
java.util.logging.FileHandler.pattern = %h/java%u.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter
 
%h는 뭔가? JDK FileHandler API 문서에서 설명을 찾을 수 있다.
  • "/" the local pathname separator
  • "%t" the system temporary directory
  • "%h" the value of the "user.home" system property
  • "%g" the generation number to distinguish rotated logs
  • "%u" a unique number to resolve conflicts
  • "%%" translates to a single percent sign "%"
     
    %hHome directory를 의미하는 것이다. 운영체제 그리고 윈도우의 경우는 버전에 따라 디렉토리가 조금씩 다르다. 기본적으로 NT 기반인 경우(필자는 XP Pro), "C:Documents and Settings로그인한 사용자 이름"이다. 홈 디렉토리 밑에 java로 시작하고, %u에 따라 파일이름에 의한 충돌을 방지하기 위한 일련번호를 붙힌다. 확장자는 log.
     
    그래서, 필자의 경우는 홈 디렉토리에 java0.log라는 파일이 생겼다. 다른 위치에 파일이 출력되도록 변경해보자.
     
    java.util.logging.FileHandler.pattern = mylog_%u.log
     
    위와 같이 변경한 후 로그가 출력되는 프로그램을 실행시키자. 클래스 파일을 실행시킨 위치에 mylog0.log라는 이름으로 파일이 생길 것이다. 나머지 설정들의 의미를 알아보자.
     
    java.util.logging.FileHandler.limit = 50000
    하나의 파일에 최대로 기록될 바이트수를 대략적으로 지정한 것이다. 디폴트는 0이며, 무제한이다.

    java.util.logging.FileHandler.count = 1
    출력파일을 몇 개 사용할 것인가. 디폴트는 1.

    java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter
    출력 포맷을 결정하는 포맷터 클래스. 기본적으로 SimpleFormatter와 XMLFormatter가 있으며, 디폴트는 XMLFormatter이다.
     
    SimpleFormatter를 사용한 경우의 출력과 XMLFormatter를 사용한 경우의 출력은 아래와 같다.
     
    SimpleFormatter 사용시
    2004. 11. 8 오후 4:49:34 CommonsLoggerExample main
    정보: hello, log
     
    XMLFormatter 사용시
    <?xml version="1.0" encoding="x-windows-949" standalone="no"?>
    <!DOCTYPE log SYSTEM "logger.dtd">
    <log>
    <record>
      <date>2004-11-08T16:37:25</date>
      <millis>1099899445360</millis>
      <sequence>0</sequence>
      <logger>CommonsLoggerExample</logger>
      <level>INFO</level>
      <class>CommonsLoggerExample</class>
      <method>main</method>
      <thread>10</thread>
      <message>hello, log</message>
    </record>
    </log>
     

  • 반응형

    http://www.sqlusa.com/bestpractices2005/centurydateformat/

    SQL Server 에서 convert를 이용해 datetime 포맷팅 스타일 값들

    내가 원하는 포맷은  yyyy/mm/dd hh:mm:ss 인데...
    지금은 111, 108 style을 이용해서 얻는데, 한방에 되는 방법은 없는건가? ^^;;;;




    How to sql format datetime with century?

     

    The following conversion options are available for sql datetime format with century:

    select convert(char, getdate(), 100) --mon dd yyyy hh:mmAM (or PM)
    select convert(char, getdate(), 101) --mm/dd/yyyy
    select convert(char, getdate(), 102) --yyyy.mm.dd
    select convert(char, getdate(), 103) --dd/mm/yyyy
    select convert(char, getdate(), 104) --dd.mm.yyyy
    select convert(char, getdate(), 105) --dd-mm-yyyy
    select convert(char, getdate(), 106) --dd mon yyyy
    select convert(char, getdate(), 107) --mon dd, yyyy
    select convert(char, getdate(), 108) --hh:mm:ss
    select convert(char, getdate(), 109) --mon dd yyyy hh:mm:ss:mmmAM (or PM)
    select convert(char, getdate(), 110) --mm-dd-yyyy
    select convert(char, getdate(), 111) --yyyy/mm/dd
    select convert(char, getdate(), 112) --yyyymmdd
    select convert(char, getdate(), 113) --dd mon yyyy hh:mm:ss:mmm
    select convert(char, getdate(), 114) --hh:mm:ss:mmm(24h)
    select convert(char, getdate(), 120) --yyyy-mm-dd hh:mm:ss(24h)
    select convert(char, getdate(), 121) --yyyy-mm-dd hh:mm:ss.mmm




    Without century (yy) (1) With century (yyyy) Standard Input/Output (3)

    -

    0 or 100 (1, 2)

    Default

    mon dd yyyy hh:miAM (or PM)

    1

    101

    U.S.

    mm/dd/yyyy

    2

    102

    ANSI

    yy.mm.dd

    3

    103

    British/French

    dd/mm/yy

    4

    104

    German

    dd.mm.yy

    5

    105

    Italian

    dd-mm-yy

    6

    106 (1)

    -

    dd mon yy

    7

    107 (1)

    -

    Mon dd, yy

    8

    108

    -

    hh:mi:ss

    -

    9 or 109 (1, 2)

    Default + milliseconds

    mon dd yyyy hh:mi:ss:mmmAM (or PM)

    10

    110

    USA

    mm-dd-yy

    11

    111

    JAPAN

    yy/mm/dd

    12

    112

    ISO

    yymmdd

    -

    13 or 113 (1, 2)

    Europe default + milliseconds

    dd mon yyyy hh:mi:ss:mmm(24h)

    14

    114

    -

    hh:mi:ss:mmm(24h)

    -

    20 or 120 (2)

    ODBC canonical

    yyyy-mm-dd hh:mi:ss(24h)

    -

    21 or 121 (2)

    ODBC canonical (with milliseconds)

    yyyy-mm-dd hh:mi:ss.mmm(24h)

    -

    126 (4)

    ISO8601

    yyyy-mm-ddThh:mi:ss.mmm (no spaces)


    127(6, 7)

    ISO8601 with time zone Z.

    yyyy-mm-ddThh:mi:ss.mmmZ

    (no spaces)

    -

    130 (1, 2)

    Hijri (5)

    dd mon yyyy hh:mi:ss:mmmAM

    -

    131 (2)

    Hijri (5)

    dd/mm/yy hh:mi:ss:mmmAM




    반응형

    이클립스 문서 번역 사이트(노트)
    퍼온곳: http://silent.springnote.com/pages/98847

    출처 : http://www.eclipse.org/articles/Article-TPTP-Profiling-Tool/tptpProfilingArticle.html

    설치를 간편하게 하기 위해선 기존 eclipse 는 그대로 두고 아래 올인원 패키지를 다운받으시는걸 추천

    http://www.eclipse.org/tptp/home/downloads/

      Copyright © 2006 International Business Machines Corp.

     Eclipse Corner Article

     

    TPTP 를 이용한 자바 어플리케이션 프로파일링

    요약
    이클립스 테스트 & 성능 툴 플랫폼 (TPTP) 프로파일링 툴은 이클립스 플러그인을 프로파일하기 위해 사용할 수 있다. 로컬 자바 어플리케이션은 물론 여러 개의 호스트나 서로 다른 플랫폼에서 동작하는 복잡한 어플리케이션에도 가능하다. 이 툴은 이클립스에 통합되어 있으며, 이클립스 상에서 동작하는 어플리케이션의 프로파일링을 해준다.
    이 문서는 TPTP 프로파일링 툴을 가지고 문제가 있는 동작을 확인하기 위해 자바 어플리케이션을 프로파일 하는 방법을 설명한다. 프로파일 세션을 시작하는 방법, 데이터 분석을 위한 다양한 TPTP 뷰를 사용하는 방법, 실행 시간이 긴 메소드를 확인하여 성능 문제를 해결하기 위해 소스 코드로 이동하는 것까지 보여준다.
     
    By Valentina Popescu, IBM
    February 21, 2006 (updated July 11, 2006)
     
    번역 : 이상훈(calm1979@gmail.com)
    2007 4 7

     

    어플리케이션 프로파일링

    지금처럼 제품을 만들어 내기 위한 단기적인 개발 사이클을 돌고 있는 상황에서는, 개발자들이 테스트, 디버깅, 코드 수정을 통한 함수의 기능적인 측면에만 중점을 두는 경향이 있다. 그러나, 대다수의 문제는 어플리케이션이 (하루 24시간, 일주일에 7일 그리고 예상치 못한 피크 타임에의 한계까지 도달하게 되는) 실제 제품으로 동작할 때까지 쉽게 드러나지 않는다.

    이런 류의 성능 문제는 디버깅 단계에서는 볼 수 없는 것들이다. 제품을 배포하기 전에 실제 상황에서 돌려보는 것이 중요하다. 어플리케이션의 동작을 분석하고, 병목현상, 객체 누수, 시스템 자원 제한 같은 성능 문제를 찾아내기 위해 프로파일링 툴을 사용하는 것은 중요하다.
    이 문서는 TPTP 프로파일링 툴을 소개한다. 그리고, 성능 문제를 확인하고 수정, 검증하기 위해 자바 어플리케이션을 프로파일링 할 수 있도록 TPTP 프로파일링 툴의 사용법을 설명한다.

    TPTP 프로파일링 툴

    이클립스 테스트 & 성능 툴 플랫폼 (TPTP) 프로젝트는 병목현상, 객체 누수 그리고 시스템 자원 제한 같은 성능 문제를 확인하고 처리할 수 있는 프로파일링 툴을 제공한다. 이 툴은 단순한 독립적인 자바 어플리케이션부터 이클립스 플러그인까지 혹은 서로 다른 플랫폼이나 다양한 머신에서 돌아가는 복잡한 엔터프라이즈 어플리케이션까지 목표로 한다.

    이클립스 프로젝트와 완벽하게 통합되어 있기 때문에, 사용하기 쉽고 확장하기도 쉽다. 이것은 사용자가 자신의 데이터 분석 화면을 붙일 수도 있고, 데이터 수집 에이전트에서 자신의 구현을 통해 데이터 수집 메타포어(metaphor)를 확장할 수 있음을 의미한다.

    이 문서는 이클립스 3.2.0을 필요로 하는 EMF 2.2.0 과 XSD 2.2.0 기반으로 하는 TPTP 4.2.0 을 사용해서 작성했다. 여기에서 이것들을 구할 수 있다. TPTP 4.2.0 설치를 위한 설명을 보려면 TPTP 다운로드 페이지 로 가면된다.

    TPTP 를 이용한 자바 어플리케이션 프로파일링

    이 문서에서 사용한 제품 카탈로그 샘플 어플리케이션은 각각의 xml 파일에 저장된 제품 정보를 분석해서 콘솔 화면에 결과를 출력하는 간단한 자바 어플리케이션이다. 제품 정보를 포함하는 xml 파일들이 위치한 디렉토리 경로는 Product.java 프로그램의 인자로 주어진다. 제품 정보를 포함하고 있는 xml 파일들은 예제 실행하기에서 제공한다.

    프로파일링 모드로 어플리케이션 시작하기

    샘플 어플리케이션을 설치한 후에, 첫 단계로 제품 카탈로그 어플리케이션을 프로파일링 모드로 실행한다. 아래 그림 1처럼 Product.java 를 선택하고 팝업 메뉴의 Profile As > Java Application 를 선택해서 어플리케이션을 프로파일한다.

    그림 1 제품 카탈로그 어플리케이션 프로파일 하기

    프로파일링 모드로 어플리케이션을 실행하는 다른 방법은 자바 퍼스펙티브의 툴바 메뉴에 있는 Profile 액션을 사용하는 것이다. Run 이나 Debug 툴바 액션 처럼, Profile 액션은 런치 설정(launch configuration) 다이얼로그를 나타낼 것이다. 다이얼로그에서 프로파일 하고 싶은 어플리케이션의 타입을 선택할 수 있다.

    자바 프로그램 인자 설정하기

    The Profile As > Java Application 을 선택하면 그림 2와 같은 런치 설정 마법사(Launch Configuration Properties wizard)가 열릴 것이다.

    이 예제에서는 제품 xml 파일의 경로를 프로그램의 인자로 넘겨준다. 이 문서의 제일 아래에서 제공되는 파일을 x:\myPath 에 풀었다고 할 경우 x:\myPath\products 를 아래 그림 2에서 보여지는 것처럼 프로그램 인자로 설정한다.

    Program arguments

    그림 2 제품 카탈로그 샘플 – 프로그램 인자(Program arguments)

    프로파일링 필터 설정하기

    다음 단계로 메소드 실행 정보를 수집하기 위한 프로파일링 옵션을 설정한다.
    이 옵션을 설정하기 위해, 런치 설정 마법사(Launch Configuration Properties wizard)의 모니터(Monitor) 탭을 선택하고, 측정하고자 하는 프로파일링 옵션을 설정한다.

    프로파일링 필터 셋(Profiling filter set)은 프로파일링 필터의 재사용 가능한 셋(set)이다. 프로파일링 필터 셋을 만드는 이유는 같은 어플리케이션을 연속적으로 실행하거나, 어플리케이션 간에 같은 종류의 프로파일링 정보를 수집하기 위해 필터 셋을 재사용하기 위함이다.
    아래에서 제품 카탈로그 어플리케이션을 프로파일 하기 위해 사용되는 새로운 필터 셋을 만드는 방법을 설명한다. com.sample.product 로 시작하는 패키지에 대해서만 사용하는 ProductFilterSet 이라는 새로운 필터 셋을 만들 것이다.

    1. 실행 정보를 수집하기 위해 모니터(Monitor) 탭에서 실행 시간 분석(Execution Time Analysis) 옵션을 선택한다.

    Execution Time Analysis option

    그림 3 실행 시간 분석(Execution Time Analysis) 옵션

    위 그림 3에서 보는 바와 같이 실행 시간 분석(Execution Time Analysis) 옵션을 선택했다. 이것은 제품 카탈로그 어플리케이션의 연속적인 실행 중에 사용될 수 있다. 이 어플리케이션의 다음 실행 때에는 “프로파일링 필터 설정하기” 단계는 건너뛸 수 있다.

    2. 프로파일링 실행 옵션을 설정하기 위해 “옵션 수정(Edit Options)” 버튼을 누른다.

    2a. "Collect boundary classes excluded by the filter set" 옵션을 선택하고 Boundary class depth 값으로 3을 입력한다.

    이 옵션을 선택함으로써, 필터 범위 내에서 실행되는 메소드들 중에 입력된 단계(depth)까지 호출되는 메소드에 대한 정보를 수집하겠다고 설정 한 것이다.

    예를 들어, MyMethod 라는 메소드에 대해 정보를 수집하도록 설정했고, M1, M2, M3, M4 메소드에 대해 필터 설정을 했다고 하자.

    다음과 같은 invocation stack 이 실행되었다고 한다면: MyMethod > M1 > M2 > M3 > M4 ( MyMethod 가 M1 을 호출하고, M1이 M2를 호출하고, M2가 M3를 호출하고, M3가 M4를 호출했다.), 2a 에서 설정한 필터 범위 값에 따라, 프로파일러는 콜 스택을 다음과 같이 보여줄 것이다: MyMethod > M1 > M2 > M3 그리고 마지막 M3>M4는 표시되지 않을 것이다. (호출 단계(depth)가 3을 초과했기 때문이다).

    Profiling Execution options

    그림 4 실행 정보 수집을 위한 설정

     

    3. 프로파일 하기 위한 클래스들을 선택하기.

         모니터(Monitor) 탭에서, 자바 프로파일링(Java Profiling) 아이템을 선택하고 옵션 수정(Edit Options)을 선택한다. 그러면 필터 셋 마법사(Filter Set wizard)가 뜬다.
    필터 셋 페이지는 프로파일 하고자 하는 클래스를 선택하기 위해 사용한다. 사용 가능한 필터들이 설정되어 있을 것이다. 그러나 이 예제에서는 com.sample.product 로 시작하지 않는 모든 패키지를 제외하는 ProductFilterSet이라고 하는 새로운 필터 셋을 만들 것이다.
    필터 셋을 만들기 위한 단계:

    3a) 필터 셋(filter set) 목록에서 추가(Add...) 버튼을 선택한다. 새로운 필터 셋의 이름을 ProductFilterSet 을 입력하고 확인(OK)을 누른다.

    3b) 그림 5에서 보는 것 처럼 두 개의 필터를 추가하기 위해 선택된 필터 셋(Contents of selected filter set) 목록에서 추가(Add…) 버튼을 누른다.

     

    Select the classes to be profiled

    그림 5 프로파일 하고자 하는 클래스 선택하기

     

     

    어플리케이션 실행하기


    런치 설정 마법사(Launch Configuration wizard)에서 확인(OK)을 누름으로써 제품 카탈로그 어플리케이션(Product catalog application)을 실행한다. 프로파일링 & 로깅(Profiling and Logging) 퍼스펙티브로 전환하겠냐는 다이얼로그가 뜨면 예(Yes)를 선택한다.
    아래 그림 6에서처럼 콘솔 화면에 프로그램 실행 결과가 출력되는 것을 볼 수 있을 것이다.

    Product application terminated

    그림 6 제품 카탈로그 어플리케이션(Product catalog application)이 실행되었다

     TPTP 프로파일링 툴은 어플리케이션과의 상호 작용을 할 수 있도록 한다. 모니터링을 일시 정지, 다시 시작 할 수 있으며, GC(garbage collection)를 실행할 수도 있고 객체 레퍼런스(object references)를 수집하거나 어플리케이션을 종료할 수도 있다.


    실행 통계(Execution Statistics) 뷰를 이용한 성능 문제 확인하기


    성능 문제를 확인하기 위해 실행 통계 뷰를 사용한다. 뷰를 열기 위해, 프로파일링 모니터 뷰에서 프로세스(process)를 선택하고 Open with > Execution Statistics 를 선택한다.
    아래 그림 7 에서 보는 바와 같이 실행 통계 뷰에서는 실행된 메소드들을 누적 시간(cumulative time)으로 정렬해서 볼 수 있다. 메소드의 누적 시간은 다른 메소드를 호출하는 것을 포함한 실행 시간이다.

    Execution statistics view

     

    그림 7 실행 통계(Execution Statistics) 뷰

    그림 7 보면, main(java.lang.String[]), readData(java.lang.String) 그리고 createParser()의 3가지 메소드가 가장 오랜 실행 시간을 사용한 것을 알 수 있다. Main과 readData 메소드가 상위에 있는 것은 걱정할 것이 아니다. 처음 것은 어플리케이션의 시작점이고, 두번째 것은 xml 파일로부터 제품 정보를 읽어들이는 것이기 때문이다.

    우리가 지켜봐야할 것은 단지 xml 파일을 파싱(parsing) 하기 위해 SAX 파서 인스턴스를 만드는 creatParser() 메소드가 높은 실행 시간을 나타내고 있다는 것이다. 이 메소드의 실행 시간이 어플리케이션의 전체 실행 시간에 42.96%나 차지한다. 실행 통계는 이 메소드가 어플리케이션의 성능을 최적화하기 위한 가능성이 있는 부분임을 알게 해준다.

    일단 이 것을 확인했으면, createParser() 메소드의 상세 실행 정보를 보기 위해 드릴 다운(drill down) 해보자.

    createParser() 메소드에서 메소드 호출 상세(Method Invocation Details ) 뷰 열기

    다음으로 우리는 createParser() 콜 스텍의 어떤 메소드가 이 메소드의 실행 시간을 느리게 하는지 보기 위해 메소드 호출 상세 뷰를 사용한다. 실행 통계 뷰에서 createParser() 메소드를 더블 클릭하여 메소드 호출 상세 뷰를 열자.

    Method Invocation Details

    그림 8 메소드 호출 상세(Method Invocation Details) 뷰

     


    그림 8에서는 createParser() 메소드의 실행 정보를 보여준다. 보는 바와 같이 이 메소드는 readData(java.lang.String)에 의해서 한 번 호출되었고 5개의 다른 메소드들을 호출함을 알 수 있다. 호출한 메소드(Selected method invokes) 테이블을 보면 newSAXParser()와 newInstance() 메소드가 createParser() 메소드를 느리게 한다는 것을 알 수 있다. createParser() 메소드가 24번 호출된 것 처럼 이 두 메소드가 24번이나 호출되었다.

    확인된 성능 문제로부터 해결책을 정의하기


    이 데이터를 분석함으로써, 우리는 createParser() 메소드의 실행 시간 향상을 위해서는 두 개의 SAXParserFactory 메소드의 샐행 향상을 해야한다는 것을 알았다. 우리는 이 메소드의 구현에 관여할 수 없으므로, 우리의 어플리케이션 실행 향상을 위해서는 이 메소들의 호출을 최대한 줄여야한다.

    해결책은 모든 파일 마다 새로운 파서를 만들지 않고, 하나의 파서 인스턴스를 만들고 이것을 재사용하는 것이다. 소스 코드를 열고 수정해보자.

    이런식의 최적화 방향을 결정하기 전에, 코드 상에서 지원을 하는지를 확실하게 해둘 필요가 있다. 예를 들어, SAXParser는 여러 쓰레드에 의해서 동시에 사용될 수 없기 때문에 인스턴스를 재사용할 수 있는 것이다. 엄격하게 말하면 인스턴스는 재사용하기 전에 reset()해주어야 한다. 변경 내용을 적용할 수 있는 코드를 작성하기 전에 포괄적인 단위 테스트 조합을 구성해두는 것도 좋은 생각이다.

     

    소스 코드를 열고 성능 문제를 수정하기

    createParser() 메소드에 대한 소스 코드를 열기 위해 메소드 호출 상세(Method Invocation Details) 뷰에서 마우스 우클릭을 하고 팝업 메뉴에서 소스 열기(Open Source)를 선택한다.

    Source code


    그림 9 소스 코드

    그림 9에 createParser() 에 대한 소스 코드가 있다. 이 메소드가 매번 호출될 때 마다 새로운 SAX 파서 인스턴스를 만드는 것을 알 수 있다.
    아래 그림 10처럼 하나의 파서 인스턴스를 만들고 모든 xml 파일을 파싱하는데에 그것을 재사용하도록 코드를 수정하자.

    Source code

    그림 10 소스 코드 수정

    그림 10에서 보는 것 처럼 전역 SAXParser 인스턴스를 만들어서 성능 문제를 해결했다. createParser() 메소드는 파서를 초기화 하고 메소드가 호출될 때 마다 만들어진 인스턴스를 리턴한다.

    다시 돌아가서 제품 카탈로그 어플리케이션을 다시 프로파일링 모드로 동작시켜 수정 내용을 검증해보자.

    성능 문제 해결 검증하기

    성능 문제 해결을 검증하기 위해, 위에서 말한 것 처럼 Product 클래스를 선택하고 우클릭해서 Profile As > Java Application를 선택한다.

    프로파일링 옵션 마법사는 나타나지 않을 것이다. 이전에 설정한 프로파일링 옵션이 어플리케이션 실행시에 사용된다. 어플리케이션을 실행한 후에 실행 통계(Execution Statistics) 뷰를 열고 실행 시간을 비교해보자.
    그림 11에 수정된 코드를 적용한 후의 실행 시간이 있다:

     

    Execution Statistics view

     

    그림 11 실행 통계(Execution Statistics) 뷰

     

    위 그림에서 보는 것처럼, 수정하기 이전에 거의 43% 였던 createParser() 메소드의 실행 시간이 단지 19%로 줄었다.
    이 성능 향상은 파싱해야될 xml 파일이 많을수록 더 커질 것이다. 따라서 카탈로그에 추가되는 제품 정보 파일이 많아질수록 어플리케이션의 실행 시간이 엄청나게 줄어들게 될 것 이다.

    결론

    이 문서에서는 TPTP 프로파일링 툴을 사용해서 성능 문제를 확인하고 해결하는 방법을 설명했다. 이 문서에서는 다루지 못한 TPTP 툴의 많은 기능이 더 있다. 만약 이 툴의 기능을 더 알고 싶다면 여기에 있는 튜토리얼 슬라이드와 사용자 가이드들을 보기 바란다.

    예제 실행하기

    "ProductCatalog_example.zip" 파일에는 이 문서에 나와있는 예제의 소스 코드를 포함하고 있다. 이클립스의 “plugins” 디렉토리에 ZIP 파일을 풀면된다. 또한 제품 xml 파일들은 products.zip 파일에 있다. products.zip 파일을 시스템의 원하는 곳에 풀어놓고, 그 경로를 제품 카탈로그 어플리케이션의 프로그램 인자로 적어주면 된다.

    Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.


    + Recent posts