'성능'에 해당되는 글 56건

  1. 2008.12.21 [Blog2Book] 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기 1쇄 오타 모음 (2)
  2. 2008.11.14 [vmstat manager] vmstat manager 2008.11.14 버젼
  3. 2008.10.14 [구매정보] 썬테크데이에서 몇가지 책을 반값에 드리네요.
  4. 2008.09.16 [vmstat manager] vmstat manager JDK 5.0 재컴파일 버젼
  5. 2008.09.09 [MacBook 사용팁] 나같은 초보를 위한 맥북 사용 팁-24 맥북 배터리 최적화하기.(링크)
  6. 2008.09.03 [분석툴] Java Path Finder
  7. 2008.09.01 [Blog2Book 자바 성능 튜닝] 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기 2쇄가 나왔습니다. (4)
  8. 2008.08.28 [Load Runner] Load Runner Fail Check (로드 런너 오류 체크)
  9. 2008.08.21 [Load Runner] LR 8.1의 VUGen (Virtual User Generator) 프로그램이 자꾸 죽을때
  10. 2008.07.21 [강의계획] 8월 11일부터 3일간 삼성 멀티캠퍼스에서... (2)
  11. 2008.06.28 [세미나자료] 2008년 07월 18일 OKJSP 세미나 자료. (1)
  12. 2008.06.24 [Performance Tool] 무료 성능 테스트 툴 - JMeter
  13. 2008.06.24 [Performance Tool] 무료 성능 테스트 툴 - MS Web Application Stress tool 다운로드와 사용법
  14. 2008.04.28 [Blog2Book] 자바 성능을 결정 짓는 코딩 습관과 튜닝 이야기 책에 대한 다양한 이야기들 (1)
  15. 2008.03.27 [DevPartner] 성능 프로파일링 하기
  16. 2008.03.27 [성능 테스트] Performance Engineering
  17. 2008.03.26 [Weblogic] 웹로직(Weblogic) 서버 쓰레드(Thread) 및 DB connection Pool 관련 설정
  18. 2008.03.21 [DevPartner] 프로파일링 시작 하기
  19. 2008.02.28 [DevPartner] DevPartner 화면 설명
  20. 2008.02.27 [링크] IBM의 성능 관련 자료
  21. 2008.02.23 [PMAT] 자바
  22. 2008.02.23 [DevPartner] DevPartner 사용시 파일 명명 방법
  23. 2008.02.23 [링크] IBM Java theory and practice: 퍼포먼스
  24. 2008.02.23 [링크] HP 관련 자바 성능 튜닝 관련 내용들
  25. 2008.02.23 [링크] Sun 성능 관련 유용한 팁들 모음
  26. 2008.02.22 [공지] 새로운 시작
이제서야 좀 여유가 생겨서 1쇄에 있던 오타를 정리한다.

저도 사람이니까, 이정도 실수는 좀 애교로 봐 주세요 ^^;

(1쇄 구매한 분들은 꼭 한번씩은 보셔야 하는데...)

내용 펼치기






Posted by tuning-java

오늘 같이 일하는 분이 오류를 하나 이야기해서....

IBM의 vmstat에 pc와 ec라는 수치가 추가되었나봅니다.
근데, 그 수치가 소숫점이라는 - -;
그래서 정수형만 확인하도록 한 소스를 소숫점 데이터도 확인 가능하도록 변경했습니다.

그리고 기본선택을 10초 단위로 선택되도록 변경하고,
3초 단위도 추가했습니다. ^^;

또 다른 버그가 있다면 말씀해 주세요.
(쓰는 분도 그리 많진 않겠지만...)

참고로 JDK 5.0 이상 사용가능 합니다.
Posted by tuning-java
어제 인터넷 서핑하다가 우연히 발견했습니다.

썬 테크 데이에서 여러 최신 책을 책을 50% DC된 가격으로 드립니다.

게다가 글 목록에 있는 제 책도 50%에...

벌써 50%가 될 때가 아니라서 출판사에 문의했더니,
출판사는 제가 이야기 할때 까지 몰랐답니다. - -;

아마도 자체적으로 손해보면서 제공해 주는 행사인듯 합니다.
http://sdnkorea.com/blog/666

제책 말고도 다른 책들도 싸게 드리니 기회되시면 이번에 구매하세요.
Posted by tuning-java
가끔 이 툴을 아는 분들이 써보고는,
JDK 5.0인데 안돌아간다는 분들이 계셔서요...

JDK 5.0 완전 초기 버젼으로 재컴파일 한 버젼을 올려봅니다.


이것도 안된다면, 그냥 JDK 6.0으로 사용하세요.
잘 될겁니다. ^^;

사용법은 이전 글 참조 하세요.
http://www.tuning-java.com/127


Posted by tuning-java
http://support.apple.com/kb/HT1490?viewlocale=ko_KR

애플사이트에 맥용 배터리 최적화하는 방법이 나와 있어서,
링크를 걸어둡니다.

근데, 내꺼는 이렇게 처리 안했는데... - -;

나중에라도 이렇게 하면 될랑가???

Posted by tuning-java
http://javapathfinder.sourceforge.net/
허광남님 블로그를 통해서 알아낸 툴...
정말 deadlocks 이나 unhandled exceptions 을 알아서 분석해줄까?
나중에 시간나면 확인해 봐야겠다.
Posted by tuning-java
Blog2Book 2nd


드디어 기다리던 Blog2Book 3호점 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기의 2쇄가 나왔습니다.
2쇄가 나오면서 드릴 말씀이 많지만....
그동안 하고 싶었던 몇가지만 말씀드리겠습니다.

드리는 말씀 1
가장 먼저 드리고 싶은 이야기는 저자는 책을 내기 전에는 정신 수양을 미리 해야한다는 사실을 알았습니다. ^^;
책이 잘 팔려서 기분이 좋기는 하지만, 악평들 때문에 기분 나쁜건 어쩔 수 없더군요.

드리는 말씀 2
그래도 이 책을 내면서 기본적인 목적은 이뤘습니다.
- 적어도 2쇄 찍기
  (제 책이 나올 수 있도록 도와 주신분들에게는 2쇄가 나와야 본격적인 이득이 되기 때문에 ...)
- 검색엔진에서 "자바 성능 튜닝"을 치면 제 책이 나오게 하기
  (구글이나 네이버, 야후, 엠파스에서 한번 쳐 보시면 압니다. ^^)

드리는 말씀 3
자바 성능을 결정짓는 코딩 습관과 튜닝 이야기는 제 첫 책입니다. (번역본과 멀티 캠퍼스 교재를 제외한...)
일반 서점이나 온라인 서점에서 팔리는 그런 책은 처음 쓴 셈이죠.
제 책에 대한 좋은 평들도 많이 있습니다. 그런 글을 블로그나 온라인 서점 사이트에 올려주신 분들에게는 이 글을 통해서 정말 고맙다고 말씀 드리고 싶습니다.

드리는 말씀 4
제 책에 대한 악평을 쓰신 분들에게는 아무말도 하지 않겠습니다.
(그와 관련된 글을 몇번 썼다가, 지웠다가 했지만, 똑똑하신 여러분들의 이야기가 다 맞겠지요. ^^; 물론 제가 실수한 부분도 있긴 합니다. ㅋㅋ 2쇄에서 수정된 부분과 오타에 대해서는 조만간 정리 해서 올리겠습니다.)

드리는 말씀 5
제 책을 앞으로 사실 분들에게는 몇 마디만 말씀 드리겠습니다.
(참고로 저는 초급, 중급, 고급 개발자의 기준은 모르겠습니다만 저는 제가 고급은 안되고, 중급 정도는 된다고 생각합니다. 초보는 아니니까 ^^)
본인이 고급이라고 생각하시는 분들중 성능에 대한 정리를 하고 싶은 분만 구매하셨으면 합니다.
절대 제 책은 고급 분들을 위한 책이 아닙니다. 제가 고급이 안되기 때문에 제가 쓴 책을 고급 분들이 보시면 안돼겠지요.
이제 갓 자바를 배우고 실무를 시작하시려는 초보 분들이라던지, 어느 정도 개발 경험이 있는데 자바 성능에 대한 궁금증을 어느 정도 확인하고 싶은 분들이 제 책을 구매하시기 바랍니다.
제가 책을 쓴 이유중 하나가 이겁니다. 매번 프로젝트에 갈때마다 로그 빼라, 스트링 잘써라 등등을 반복하는 것이 너무나 힘들고 싫었습니다. 그런 내용을 쓰다보니 자바 초보 분들을 위해서 기본적인 API에 대한 설명을 넣어야 이해가 쉽겠더군요.

제 책은 웹 시스템에서의 WAS에서 성능에 영향을 주는 부분을 어떻게 코딩해야 하는지를 정리한 책입니다. WAS자체를 개발하고, 코어 부분을 튜닝하는(0.01 ms가 중요한 그런)분들이 읽어야 하는 그런 책이 아닙니다. 그런 분들은 자바 언어 스펙 (번역본이나 원서), 이펙티브 자바, 자바 퍼포먼스 튜닝(한빛에 번역서가 있습니다.)등을 읽으시면 더 도움이 많이 될것 같습니다.

긴 글 읽어 주셔서 감사합니다.

PS : 만약 "자바 성능을 결정짓는 코딩 습관과 튜닝 이야기"의 5쇄가 나온다면,
"자바 성능을 결정짓는 코딩 습관과 튜닝 그 두번째 이야기"로 보다 심도 깊은 이야기를 할까 생각하고 있습니다. ^^;
  
Posted by tuning-java

이 글은 성능테스트를 로드런너를 하는 분이 이해를 하실 수 있는 내용이므로,
관련없는 분들은 바로 패쓰 하시기 바랍니다. ^^;

성능 테스트를 수행할때 반드시 해야하는 작업이 있다.

바로 오류 체크 로직을 넣는 작업이다.

자세히 보기..

 추가로 
lr_get_transaction_duration("트랜젝션이름")
함수를 사용하면 해당 트랜잭션의 응답속도를 얻을 수 있으며,
이 값이 허용치 이상일 경우 ERROR로 처리할 수도 있다.  

Posted by tuning-java
로드런너를 자주는 사용 안하고(라이센스가 워낙 고가라...)
가끔 사용하는데,
그 비싼 툴이 내 PC에서 스크립트 작업을 할때 자꾸 죽는 현상이 발생한다.
(스크립트 다 짜고 저장도 안했는데 컴파일 작업할때 죽으면 빼도 박도 못한다. - -)

LR 9.1이 너무 무거워서 되도록이면 사용을 안하고 있는데...

이런 경우에는 LR 9.1을 HP 사이트에서 다운로드해서
스크립트 작업을 한 이후에 8.1에서 하는것이 가장 좋은 방법인듯...
웬만한 웹 스크립트는 9.1에서 스크립트짜고 8.1로 돌리면 잘 돈다.


LR 8.1 FP4라는 업데이트를 사용하더라도 별다른게 없다.
(상태가 더 안좋아 진다 - -)

Posted by tuning-java
8월 11일부터 3일간 삼성 멀티캠퍼스에서 내 책을 교재로 하는 자바 성능 튜닝과 관련된 과정이 개설된다.
분기당 한번씩 저자 직강으로만 하기로 했는데, 이번에 해보지도 못하고 없어지는건 아닌지 모르겠다.

과정 설명은 아래 링크 참조.

http://www.multicampus.co.kr/education/course.do?method=detail&classify_code=000100100000&course_code=39775


근데, 휴가기간이라 신청한 사람이 별로 없는듯...
5명은 넘어야 과정이 개설될텐데... - -;

괜히 과정 만들자고 했나 ???

Posted by tuning-java



2008년 7월 18일 OKJsp 와 함께하는 세미나에서 발표할 자료입니다.

원본을 PDF로 변환하였습니다.

상황에 따라서 내용이 변경될 수 도 있습니다.

여기에 있는 모든 내용은 불펌하시면 안됩니다. ^^;

만약 가져가실 경우 출처를 명시해 주시기 바랍니다.

(뭐 가져가셔도 별 필요는 없겠지만.. ㅋㅋ)

컬러판은
http://www.slideshare.net/javatuning/okjsp-performance-and-java-tuningv20080702/
에서 확인하실 수 있습니다.

Posted by tuning-java

무료로 사용하기 좋은 툴중 또 다른 하나는 JMeter 이다.

한빛 미디어 홈페이지에 JMeter 설치부터 사용까지 자세히 정리되어 있는 내용이 있어 링크를 걸어 두겠다.

http://network.hanb.co.kr/view.php?bi_id=1520
http://network.hanb.co.kr/view.php?bi_id=1521
http://network.hanb.co.kr/view.php?bi_id=1522

물론 상용툴을 따라가기는 어렵겠지만,
무료툴도 어느정도 사용할 만한 정보들을 제공하기 때문에 한번 사용해 볼만 하다.

Posted by tuning-java
나온지 꽤 되었지만,
그닥 나쁘지도 않은 성능 테스트 툴인
MS Web application stress tool 이라는게 있다.
다운로드는
http://www.microsoft.com/downloads/details.aspx?FamilyID=e2c0585a-062a-439e-a67d-75a89aa36495&DisplayLang=en
요기 에서 하면 된다.

2002년에 만든이후 아무런 유지보수가 되고 있지는 않다.
Vista에선 확인해 보진 않았지만, XP에서도 잘 돌아간다.

사용법은 그리 어렵지 않으나, 결과를 이해하는 건 그리 쉽지 않은 그런 툴이다.
사용법은 아래 링크를 통해서 확인하면 된다.
http://support.microsoft.com/kb/313559/ko


Thread 생성해서 URL에 요청하는 것 보다는 나을 수도 있으니,
이 툴을 한번 써 보기 바란다.
Posted by tuning-java

책이 나온지 거의 두달 되어가니 여러분들의 이야기들이 블로그에 올라와 있다.

좋은 리뷰도 있고, 좋지 않은 리뷰도 있네요. 모든 의견이 중요하다고 생각합니다.

단지, 이 책에서 부족하다고 생각들 하시는 튜닝의 기법이라든지, 툴에 대한 자세한 내용은 다음 책을 위해서 아껴 두었다고 너그럽게 생각해 주시면 감사하겠습니다.

이 책을 사려는 분들이나, 다양한 의견을 공유하시려는 분들은 아래의 링크를 클릭해 보시면 됩니다. ^^;

<<<<< Yes24 사이트의 주옥같은 리뷰들 보기 >>>>>

최종 update date : 2008. 05. 10.

Posted by tuning-java

참고로 이 설명은 [Blog2Book 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기] 책을 읽는 독자분들이 부록으로 제공되는 DevPartner for Java를 보다 쉽게 사용할 수 있도록 작성되었으며, 설치시 14일간 기능의 제한이 없는 임시 라이센스가 생성됩니다.

nmshell에 대해서도 봤으니, 이제 성능 프로파일링 하는 방법에 대해서 알아보자.
참고로 여기서 본인은

nmshell -perf -config Test

로 nmshell을 수행했다.

정상적으로 nmshell을 수행했다면, nmshell 창에서 해당 WAS나 어플리케이션을 시작하는 스크립트를 수행하자. 그러면 다음과 같은 화면이 나타난다.

예전에 광고에서 비트박스하는 방법을 알려주면서, 북치기 박치기만 잘하면 된다는 광고를 보았을 것이다. 그것처럼, DevPartner에서 성능 프로파일링을 하기 위해서는 두가지 버튼만 잘 누르면 된다.
그 버튼은 "Clear Collected Data" 와 "View Results" 버튼이다.

Clear Collected Data 버튼 : 지금까지 수집된 모든 데이터를 지운다.

View Result 버튼 : 지금까지 수집된 데이터를 보여준다.

쉽게 말하면, 어플리케이션을 구동하는 동안 수집된 정보는 필요가 없으므로, 화면을 수행하기 전에는 Clear Collected Data를 누른다. 그런 다음, 화면을 수행하고 나서는 View Result 버튼을 클릭하면 된다.

그러면 위와 같은 화면이 새로 나타나는데, 이제부터 수집된 데이터를 기반으로 분석을 하면 된다.

근데 책에서 몇번이고 강조를 했지만, 서버를 띄우고 나서 가장 처음 해당 화면을 수행할 때의 결과는 절대 사용하면 안된다. 잘못하면 정상적이지 못한 시스템 분석이 되기 때문에 첫번째 화면을 수행한 이후에는 반드시 Clear... 버튼을 클릭하고, 그 다음에 화면을 1회, 10회 ... 수행한 이후에 View Result 버튼을 눌러 결과를 확인하기 바란다.

결과를 확인하는 방법은 가장 어려운 부분중 하나인데, 이에 대해서는 직접 터득하시기를 권장한다. 왜냐하면, 말로 설명해도 한시간 이상 소요되는 작업이고, 아무리 말로 설명해도 이해하기가 쉽지는 않기 때문이다.

뭐 많은 분들이 원한다면 나중에 관련 내용이 추가 될 수도 있다. 

다음에는 메모리 프로파일링 하는 방법에 대해서 알아보겠다.

Posted by tuning-java

출처
http://www.theserverside.com/tt/articles/article.tss?l=PerformanceEngineering

Performance Engineering - a Practitioner's Approach to Performance Testing

나중에 심심할때 함 읽어봐야 겠다.


Context/Introduction

"The application is horribly slow.", "I don't get the response even after I get my coffee.", "This application is useless". Sounds familiar? How many times have we heard these quotes or or felt like that ourselves? The common thread between these statements is that the performance of the application is not good.

Performance - the (in)famous buzzword. What is it? What does it mean? In this article, we'll touch upon what is involved in testing an application for performance.

With every passing day, organizations are becoming more and more conscious about the performance of their Enterprise Solutions. As the IT industry matures and the technology evolves, so does the awareness about expectations from an Enterprise Application.

Focusing just on the design / implementation and Zero-functional-defect solutions are things of the past. With increasing maturity in technology and IT staff, the 'Non-functional' aspects of the system are fast becoming focus-areas.

So what exactly are the non-functional aspects and/or requirements?

Non-functional requirements (NFRs) tell the IT team, about the kinds of usage and load the application will be subjected to, and the expected response time. We'll go into the details of this "response time" shortly.

NFRs define the Service Level Agreements (SLAs) for the system and hence the overall Performance of the Enterprise Application. Besides performance SLAs, NFRs also cover several other aspects, such as security, but for this article we are concerned with performance related objectives only.

Managing and ensuring the NFRs (SLAs) for an Enterprise Application is called Performance Engineering. Performance engineering is a vast discipline in itself which includes Performance Modeling, Performance Prototyping, Performance Testing, different types of analyses, Performance Tuning, etc. This article will not explain Performance Engineering, Queuing Theory and the science behind the various laws. This article just covers the basics about the Performance Engineering and key activities in Performance Testing.

How to describe Performance of a 'System'

The performance of any system can be expressed in many ways by different stakeholders of the system. For example, When a business analyst gives performance (or non-functional) requirements, it might be in some format as follows:

  1. "there will be at least 100 users on the system all the time",
  2. "System should respond back in 'acceptable time'".

These statements have to be translated to somewhat more technical terms as described below. Once we understand these terms, we'll reword these Performance requirements.

To define the performance of any System (Software/hardware/abstract) following technical parameters should always be used in conjunction -

  • Response Time: Response time specifies the time taken by the system to respond back with the expected output. For an enterprise application Response time is defined as the time taken to complete a single business transaction. It is usually expressed in seconds.
  • Throughput: Throughput refers to the rate which the system churns expected outputs when the designated input is fed in the system. In other words, for an Enterprise Application, throughput can be defined as the total number of business transactions completed by the application in unit time (per second or per hour).

Usually, per second or per hour is the standard, since per day (or per diem) is a very wide unit. Most business users utilize an Application during typical 8 hour business window. Normally there are some peaks & some troughs in the input, so the volumes per day should not be averaged to an hour. All the mathematical distributions (normal, Poisson, uniform) come handy over here.

  • Resource Utilization: For any system to consume an input and produce the designated output, certain resources would be required. The amount of resources consumed by the system during processing that request, defines the resource utilization. There can be different resources factored in, such as processor, disk (i/o controller), memory etc. Utilization of 80% is considered an acceptable limit. Normally utilization of 70% warrants ordering of additional hardware.

Now that we know basic technical terms for expressing performance facts about a system, we'll try to rephrase the above Performance Requirements.

  1. We should ask the question whether all the users would be carrying out a transaction simultaneously or they would be just logged on. The answer of this question would lead us to the throughput expectations. In case of pre-existing applications (or using applications having similar profile), we can also arrive at the transactions/sec or throughput requirements from logs files (e.g., HTTP logs of web-applications.)
  2. The vagueness of "acceptable" times needs to be removed by defining the response time requirements clearly, e.g. 2 seconds, 2 hours or 2 days.

Let's begin then...

Performance test planning

He who fails to plan, plans to fail

As in all aspects of life, planning is very important in Performance Testing. We present the simplistic approach to planning a Performance testing exercise in the sub-sections below.

How to represent the SLAs? - Workload model/distribution/pattern

The first step of any IT project is usually requirements gathering. Similarly, for any performance testing project, its very important to gather the SLAs / NFR of the system against which the tests will designed and executed.

Performance testing depends as much on how well the SLAs are gathered as much as on how well they are represented. A well represented non-functional requirement can help a long way in the rest of the planning and analysis activities.

The various throughput rates, load figures, list of transactions, types of transactions, response times and projected growth in coming years are captured in a document called the Workload. Workload captures the load pattern, load distribution, transaction distribution, peak windows etc.

The workload should be thoroughly reviewed by the various stakeholders of the system, like, architects, business users, analysts, designers and performance engineers.

What to test? - Identifying Transactions

Once the Workload model has been prepared and reviewed thoroughly, the next step is to Identify candidate transactions. If we select too few transactions, the system might contain a serious SLA mismatch and if we select all the transactions, we might be heading towards a never ending performance test cycle.

The famous 80-20 rule comes in handy here. In most applications, 20% of the transactions cover 80% of application's core functionality (to be confirmed with the help of application experts). Once the workload model has been created, this step is fairly easy and straight forward.

It's also important to classify the transactions as the Performance Testing would be carried out differently for each type. The transactions could be very broadly categorized as online - where user submits a request and gets a response, and batch - where user submits a list of jobs and does not wait for the completion. The transaction mix also has to be identified, viz. transaction A has 50% requests, transaction B has 30%, and transaction C has 20%. All of A, B, C can occur together. This helps in deciding the mixed tests.

Also at times, there might be certain transactions which do not qualify as candidate transactions according to the 80/20 rule, but might be critical to business. Such transactions should also be considered for performance tests and all such transactions can be clubbed in one run to get a benchmark reading for analysis.

Where to perform tests? - Environment Setup & Planning

For Performance Testing, it is ideal to get an environment with the same capacity as the production/live environment. Many developers are of the opinion that one deliverable/outcome of performance testing/engineering exercise is to provide hardware projection for production use, which is perfectly right. Capacity projection and Production hardware gauging is altogether a vast topic. So for simplicity sake, we restrain ourselves to Production like environment (considering an earlier release of the application is already live on some hardware).

Besides the deployment hardware, there are many other pieces of hardware that would be needed to facilitate load testing. These can be broadly classified as load generation nodes, stub nodes and monitoring.

Load generation nodes are the machines used to generate load for the applications. These nodes are used to host the load generating software, such as LoadRunner, WinRunner, etc. Some open source alternatives are also available. Some custom scripts will have to be written which can run on these nodes to generate load on the system. These tools also help in monitoring the resource utilizations.

However it is not mandatory to use only these tools. Depending on the complexity some custom stubs may be written to do the testing.

Monitoring nodes usually can be the same as load generating nodes, since most of the load-generating software packages are also equipped with monitoring capabilities. Monitoring is an inherent aspect of Performance Testing. All the resource utilizations need to be monitored throughout the duration of the test to

  • ensure all the utilizations are within limits
  • identify the bottlenecks
  • The rate at which transactions are completing
  • Number of failed transactions...etc...

Stub nodes are the ones which will be usually hosting a stub to simulate some part of the software or external system that can not be included in the performance test runs - such camera or scanner devices that are operated manually, which wouldn't be a valid option for a repeatable performance test.

Data Preparation

Any enterprise system is usually programmed to process data. Thus, data planning for the performance testing of the system is a vital step. This directly affects the success of the Performance Testing exercise.

Data required for load tests can be broadly categorized as -

Initial/Retention Data - The performance of database is very much dependent on the amount of data present in the tables. When the application is in production, there is certain amount of data present in respective tables. While carrying out performance testing, it is necessary to have at least equal amount of data in the Test environment. In fact, depending on the system upgrade plans, the data in the test environment could be a multiple of production data.

Having same amount of data is one thing, and using the same distribution of data as in production is another. The distributions of data straight away affect the index performance and in turn the application performance.

The amount of data and its distribution should be validated by business and/or IT dept. before proceeding with Performance Testing.

Test Data - Once the retention data is fine, we turn our attention to test data. The same concepts as amount and distribution apply to test data as well. This time, we have to take concurrency into consideration too.

Designing scenarios

Any testing activity is comprised of the test cases and test-suite encompassing those tests. For performance testing there are some standard tests which are usually conducted on the candidate transactions of the system, depending on the nature of those transactions. The following subsections give a brief insight in each of those test scenarios.

Isolated runs

"Isolated" means running one transaction at a time. By running a single transaction and observing its behavior, we can see if it is able to utilize the hardware well. We can also see if it is able to meet its throughput requirements by running alone at least. The readings taken can also help in capacity planning (part of advanced Performance Engineering).

Usually isolated runs are preceded by Baseline / Calibration runs, where in just a single run of each transaction is executed to get the benchmark response times for all candidate transactions.

Mixed runs

"Mixed" means running all/multiple transactions simultaneously. This helps in identifying if all the transaction throughputs are met when multiple transactions are occurring parallely, i.e., it also tells us the effect of transactions on each other.

There are two schools of thought in the order of execution of these tests.

  • First, run mixed test in the beginning. If everything is fine, then we are saved efforts for isolated tests.
  • Second, run isolated tests in the beginning followed by mixed test. This is more useful when you want to determine the scalability of the application and do any capacity planning.

Trickle feed

This is mainly applicable in case of batch type of loads - e.g. the load may come as 'n' messages per five minute block.

Backlog runs

This is a typical batch load. Sometimes it might happen that the application receiving messages (say Application A) is down for long time, but the feeding application (say Application B) is continuously putting messages. Now when the application A comes up, how it behaves, can be found out by this testing.

Endurance

It has been observed that whenever a system is running for multiple days or months without downtime, its memory utilization increases or throughput falls or some exceptions occur. To find out if the application behaves fine even if run for longer duration, this test is used.

Stress

Sometimes, as the load on the system increases, e.g. on Christmas Eve for retail or shipping applications, the system throws errors or behaves unexpectedly. The stress test targets exactly this behavior. Determining that the software handles the load gracefully without crashing is the aim of this test.

Preparing Reports

Presenting results in an understandable format is normally a neglected area. If you don't do that, you are reaping only 20-30% benefits of Performance Testing. Properly presented results will enable business stakeholders to make informed decisions. Also, when it is time to do Performance Testing for the next version of the same application and if you don't have properly documented results (and if the people who did the exercise are gone), then you need to start all over again.

Key graphs

Here are some key graphs that should be created while executing Performance Testing and should be presented in a Performance Test Report.

CPU Utilization vs. No. of users

This graph tells us whether the CPU utilization increases with increasing users. It also tells us about bottlenecks as well as what is the maximum number of users that can be supported.

Throughput vs. number of users

This graph tells us if throughput increases with increasing number of users. This graph should have a similar shape as CPU Utilization graph.

Response Time vs. throughput

The response time should be fairly constant with increasing throughput. If it is not, it is most likely a bottleneck.

Besides the above mentioned graphs, depending on the nature of transactions and criticality of various components, a few other graphs can also be included in the report, such as network bandwidth & latency graphs, memory utilization graphs, disk / i-o utilization graphs for disk/i-o intensive operations, etc.

Best Practices

Automation with handy scripts

Script writing is an inherent part of any Performance Testing exercise. A lot of time is spent in ensuring the begin state of the test is proper. It might involve restarting servers, deleting extra data other than retention data, cleaning up log files, taking backup of some data, checking if some pattern exists in a log file, etc. Since each test needs to be run for 'n' number of times, automating these small tasks goes a long way in reducing time needed for each run.

Identify DB backups after crucial runs

During the course of Performance Testing activity there are bound to be different patches on application, database side. These changes are seemingly trivial but potentially devastating. It is a good idea to take the backup of data in the database and configuration files for the application before applying new patches to either application or DB.

Cross check Little's law

One of the basic queuing theory principles applied in SPE (Software Performance Engineering) is Little's law (a). It states that the total number of users in the system is equal to the product of throughput and response time. While calibrating your load test runs, one should always cross check the test results (throughput, response time, user-load simulated) to identify whether the load generator nodes themselves are not becoming the bottleneck in the system.

Designing scenarios to achieve right mix of transactions

Do not tune, if you don't have to.

There is a thin line separating Performance testing from Performance tuning. Unless really required, the tuning of various parameters of different components in the system should not be done. You will find many articles, which warn against tuning the systems. Most of the system components come with default values that are optimal. If we start looking for tuning of all the components, the duration of performance testing exercise will no longer be under control.

People Aspect

Performance Testing is a very strategic activity in the lifecycle of any Application. More often than not, you will have to deal with stakeholders who are apprehensive about the need of this activity, some people (especially DB, OS admins) who don't want the extra load this activity puts on them, software vendors who don't want additional defects on them, and many more. For the success of Performance Testing, it is important to take all these people along & explain (or thrust as the case might be) the inevitability of this exercise & how life would be easier when the application goes in production.

Environment availability is the biggest constraint which might force working in shifts, long hours, etc.

References

Authors

Alok Mahajan is Technical Architect with Infosys Technologies and specializes in Performance Engineering and Database designs. He has a total experience of more than7 years and has worked extensively on Performance Engineering assignments for more than 2 years, which uniquely positions him to write on the subject of performance. His areas of interest include Business Intelligence, Databases, Datawarehouse design/modeling.

Nikhil Sharma is Technical Architect with Infosys Technologies. For more than7 years, he has been involved in architecting and designing Enterprise Applications primarily on J2EE platform. For past2 years he has been working on Performance Engineering projects. He is also a Sun Certified Enterprise Architect for J2EE Platform (SCEA). His areas of interests are SOA, Integration Architectures, Portals.

Posted by tuning-java

WebLogic Server Performance and Tuning
Weblogic의 성능 관련 세팅과 관련된 정보가 포함되어 있다.
http://edocs.bea.com/wls/docs92/perform/intro.html

참고로 Weblogic 8.X 이상에서 Thread 설정은 다음과 같이 한다.

Weblogic 콘솔에 로그인(보통 http://url/console 로 접근하면됨.)
-> domain 명에서 servers 를 확장후 해당 서버이름을 선택
-> Configuration 의 General tab 선택 -> 화면의 하단에 있는 Advanced의 show를 선택
-> 가장 하단의 Configure Execute Queues 를 선택
하면 Thread 관련 설정 화면으로 이동된다.

혹시 모르실 수도 있으니, DB Connection 관련 설정은 다음과 같이 한다.

Weblogic 콘솔에 로그인
-> Services 의 JDBC의 Connection Pools 에서 설정. (관련 설정이 없으면 새로 맹근다. ㅋㅋ)

Posted by tuning-java

참고로 이 설명은 [Blog2Book 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기] 책을 읽는 독자분들이 부록으로 제공되는 DevPartner for Java를 보다 쉽게 사용할 수 있도록 작성되었으며, 설치시 14일간 기능의 제한이 없는 임시 라이센스가 생성됩니다.

DevPartner 서버 (실제론 톰캣 서버다.)가 제대로 기동되고 있는 상황에서(DevPartner 관리 페이지가 뜨는 상황에서) 프로파일링이 가능하다.

시작하기 전에 앞서 알려드렸던 윈도우즈 서비스 목록에 관련 서비스가 시작되어 있는지 확인하는 것이 좋다.

프로파일링 하는 방법은 크게 두가지 인데, 한가지는 Administrator 툴에서 WAS관련 값을 지정하는 방법이다. 한번 지정하면 다음부터는 클릭만으로 서버를 띄울수 있어 편리하다. 하지만 난 이 기능을 안쓴다. 한 사이트에 가서 있어 봤자 며칠 안되기 때문에...

다른 방법은 nmshell을 사용하는 방법이다. nmshell은 윈도우나 Unix의 커맨드 창에서 이 명령어를 수행하면 이름 그대로 하나의 가상 shell이 추가된다.
(기본적으로 DevPartner를 깔면 nmshell이 있는 DevPartner의 bin 디렉토리가 "Path"에 잡히기 때문에 그냥 아무데서나 실행하면 된다.)
그냥(아무 옵션 없이) nmshell을 수행하면 다음과 같은 결과가 나온다.

C:\Program Files\Compuware\DevPartner Java Edition\bin>nmshell
DevPartner Java Edition Utility that profiles arbitrary commands

  Usage:

      nmshell [DPJ Options] -config <name>
          Launches a new shell from which all Sun(R) Java(tm) apps
          will be profiled by DPJ

      nmshell [DPJ Options] -config <name> -exec <command> [<param>...]
          Runs <command> with specified params under DPJ profiling

  DPJ Options:

      -config <name>    Run under configuration named 'name'
      -perf     Profile CPU performance (default)
      -mem      Profile memory usage
      -cov      Profile code coverage
      -batch    Run in batch mode (do not bring up DPJ UI)
      -nmv      Verbose operation
      -help     Displays this text

C:\Program Files\Compuware\DevPartner Java Edition\bin>

보면 알겠지만, -perf 옵션을 주면 성능 프로파일링을, -mem 옵션을 주면 메모리 프로파일링을, -cov 옵션을 주면 커버리지 프로파일링을 한다. 그리고 가장 중요한 것은 -config를 하고 나서 이름을 지정하는 것이다. 여기서의 이름은 DevPartner 의 UI에서 만든 config 이름이다. (이 config에 대해서는 나중에 시간나면 자세히 설명을 올려놓겠다.)

WAS를 띄우기 전에 다음과 같이 수행을 한다.

nmshell -config Test -perf

이렇게 지정을 하면 성능 측정을 하고 "Test"라고 지정되어 있는 config 조건에 맞는 성능 측정을 한다는 의미가 된다.

그럼 화면이 떴을때 부터 하는 일은 다음에 정리하겠다.

Posted by tuning-java

참고로 이 설명은 [Blog2Book 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기] 책을 읽는 독자분들이 부록으로 제공되는 DevPartner for Java를 보다 쉽게 사용할 수 있도록 작성되었으며, 설치시 14일간 기능의 제한이 없는 임시 라이센스가 생성됩니다.


DevPartner의 화면에 대한 간단한 설명을 해 보고자 한다.
먼저 Welcome 화면이다.

그냥 별 내용은 없는데, 오른쪽에 Java Platform Performance 라는 링크를 누르면 자바의 성능에 대한 관련 책이 링크로 제공된다.

(인터넷이 되는 곳에서만 확인할 수 있다.
다음은 Application Testing 화면이다.

이 화면에서는 WAS 기반의 시스템이 아닌 단독 자바 애플리케이션을 테스트 할 때 사용된다.

이 화면을 사용하기 위해서는 DevPartner의 프로그램 그룹에 있는 Utility의 Administration 이라는 프로그램을 사용해야만 하는데, 나는 설정하기 귀찮아서 이 기능을 사용하지 않는다.

이번 화면은 Application Server Testing 화면이다.

관련 내용은 Application Testing 과 비슷하기 때문에 생략 하겠다.

이제부터 중요한 화면이다.

위의 화면은 Session Files 라는 화면인데, drop down 메뉴에 기본적으로 Default라고 나타날 것이다.
만약 여러분이 config를 다른 이름으로 지정한다면 그 이름도 여기에 나타날 것이다.
config 지정하는 것은 "WAS 모니터링 시작하기"편을 통해서 확인해 보기 바란다.

다음은 현재 프로파일링 중인 어플리케이션 세션의 목록을 보는 화면이다.

여기의 목록에서 프로파일링 중인 대상을 더블 클릭하면, 데이터를 수집할 수 있는 화면으로 이동한다.

마지막 화면은 설정하는 화면인데, 가장 중요한 화면중 하나이다.

이 내용은 영어를 읽으면서 하나 하나 설정해 보면 되는데, 만약 자세한 설명이 필요하다는 분들이 많다면,

자세한 설명을 나중에 추가하도록 하겠다.

Posted by tuning-java

IBM의 성능에 대한 정리가 잘 되어 있는 사이트이다.

http://www-128.ibm.com/developerworks/rational/library/4228.html


http://www-128.ibm.com/developerworks/rational/library/4169.html

아래 내용이 젤 중요
http://www-128.ibm.com/developerworks/rational/library/4257.html


좋군...

Posted by tuning-java
TAG IBM, java, 성능
http://www.alphaworks.ibm.com/tech/pmat

PMAT

자바 메모리 덤프를 분석하는 굉장히 유용한 툴
Posted by tuning-java

프로파일링 툴을 사용할때,

프로파일한 결과파일의 명명규칙을 정하지 않으면,
나중에 결과정리할 때 곤혹을 치루게 된다.(다 열어봐야 하니까...)

그래서 아래와 같이 하시면 편리하고,
되도록이면 이 표준을 사용하는게 나을듯....

예) DevPartner사용시
01_Login_2nd_10Time.tts

가장 앞의 01은 프로파일한 순서 Login이 아닌 다른 menu를 선택하면 02가 된다.

그리고, 두번째는 해당 업무 명,
세번째는 해당 업무를 프로파일한 횟수(첫번째한건지, 두번째 한건지...)
마지막 10Time은 해당 화면을 10번 클릭한 것을 명시한 것이다.
이렇게 하면 파일명으로 sorting해도 나중에 보기 편리하다.
작업할때는 보통 Date로 sorting해서 작업하면 된다.(필요없는 파일을 삭제하기 위해서.)

Posted by tuning-java

http://www.ibm.com/developerworks/kr/library/j-jtp09275.html

IBM에서 작성한 성능과 관련된 문서.

Java의 성능과 관련된 내부 구성이 어떻게 되는지를 확인할 수 있는 좋은 문서

이 사이트는 한글로 구성되어 있기 때문에,

영어 울렁증이 있는 분들에게도 많은 도움이 될 것이다.

Posted by tuning-java



Java Performance Tuning 웹 사이트 http://www.hp.com/dspp에 가서
“Performance Tuning Java”검색

Java 관련 hp 제품 http://www.hp.com/go/java

Posted by tuning-java
 
이 링크 따라 가면 Sun에서 발표한 자료들과
 
고민하고 있는 내용들을 알 수 있음.
Posted by tuning-java
Blog2Book 자바 성능을 결정짓는 코딩 습관과 튜닝 이야기가 출간되면서 새롭게 시작되는 블로깅.

사용자 삽입 이미지


Posted by tuning-java