제목 : 웹기반시스템하에서의 성능에 관한 이론적 고찰
글쓴이: 이원영(javaservice) 2001/12/19 03:46:51 조회수:45420 줄수:68 |
|
웹기반시스템하에서의 성능에 관한 이론적 고찰
최근문서수정: 2002.02.22 21:06
최근문서수정: 2002.02.25 16:27
최근문서수정: 2002.02.26 20:00
웹기반 시스템의 역사가 짧다보니, 웹기반시스템에서 어떻게 성능을 측정할 것인가,
무엇이 성능인가, 성능은 어떤 특성들이 있는가, 동시사용자는 무엇이고 어떻게 측정되어
지는가, 스트레스테스트는 어떻게 하는가에 대한 이론적 지식이 많이 부족한 듯 합니다.
본 강의는 상이한 웹어플리케이션서버(Web Appliction Server) 환경 하에서의
벤치마크테스트(Benchmark Test)를 수행하고, 인터넷뱅킹을 비롯한 여러 금융권 사이트와
증권사이트의 장애진단 및 튜닝을 통해 습득한 웹기반 시스템하에서의 성능(Performance)에
관한 이론적 지식을 집대성한 것입니다.
본 강의는 현재 웹기반시스템을 운영/관리하고 있는 시스템관리자나, 네트워크를 포함한
시스템 아키텍쳐를 고민하는 아키텍터, 제품선정이나 시스템 도입을 위한 벤치마크테스트를
시행할 기술담당자, 웹 기반 시스템에 대한 튜닝을 시행할 엔지니어, 혹은 웹프로그래머
중에서도 중급 이상의 소프트웨어 아키텍터를 지향하는 개발자, 그리고 성능에 대해
나름대로 이론적인 특성들을 알고자 하는 이들을 대상으로 하고 있습니다.
본 강의는 이론적인 부분에 많은 지면을 할애하고 있으며, 실질적인 튜닝을 위해 뭘
어떻게 고친다는 식의 것들은 기술하지 않았습니다. 기본적인 개념이 잡혀지면 어떻게
하면 되는가는 스스로 충분히 찾아낼 수 있을 것으로 믿기 때문입니다.
이 강의를 통해, 웹기반 시스템의 성능에 대한 이론적 특성을 이해하고, 향후 시스템
성능진단이나 하드웨어용량증설 시에 참고할 수 있을 것이며, 어떻게 웹기반의
시스템에서의 성능을 측정할 것인가, 어떻게 튜닝할 것인가에 대한 고민의 첫 출발이 될
것으로 믿습니다.
본 문서는 저자의 동의없이 무단배포를 하시면 안됩니다.
Document Version 1.2.9 2002.02.21
Document Version 1.2.9.2 2002.02.25 16:27
Document Version 1.3.0 2002.02.26 20:00
------------------
2002.01.21 추가
지금까지의 자료는 항상 하나의 응용어플리케이션에 대한 TPS와 Response Time을
구하고, 그 특성을 이해하는데 그쳤습니다. 그러나, 실재 시스템은 어떠합니까?
Servlet/JSP는 수십에서 수백개이고, 그 중 자주 사용되는 것과 어떤 것은 전혀
사용되고 있지 않는 등, 개별응용어플리케이션들은 각기 서로 다른 빈도로 호출되고
있을 것입니다. 이 처럼, n개의 서로 다른 응용어플리케이션들이 서로다른 호출빈도로
요청되어 질 때, 각 응용어플리케이션들의 성능이 어떻게 서로 연관관계를 맺는지에
대한 이해가 필요할 것입니다. "다차원 유클리드공간에서의 거리개념"은 이것을 풀어주는
멋진 해법을 제공하고 있더군요. 현재, 이 부분에 대한 고민이 완성단계에 있습니다.
적어도, 다음 달 2월 21일 열릴 "한국자바개발자 컨퍼런스"에서는 이 부분이 추가되어
강의를 할 수 있을 것으로 생각합니다. (기대되지 않습니까?)
------------------
2002.02.21 추가
3장 n개의 서로 다른 어플리케이션간의 영향도와 성능지수를 구하는 프리젠테이션 부분을
완성했습니다. 그러나, 아직 자료에 설명은 추가하지 못했습니다. 조만간 다시 올리도록
하겠습니다.
--------------------
2002.02.26
모든 프리젠테이션에 대한 하고자 했던 설명글을 모두 작성했습니다. 뭔가를 하나
이뤘다는 흥분을 감추지 못하겠네요... 다음 토픽은 "벤치마크 테스트 방법론"입니다.
시간나는대로 틈틈이 작성토록 하겠습니다. 기대해 주세요.
PS: 프린트 하실 때 반드시 "인쇄대상"은 "슬라이드노트"로 선택하시고, 또 흑백프린트의
경우 추가적으로 반드시 "회색조"를 선택하여 프린팅 하세요.
================================================
자바서비스넷 이원영
E-mail: javaservice@hanmail.net
PCS:011-898-7904
================================================
 PerformanceConcept.zip (659325 Bytes)
|
제목 : Re: 웹어플리케이션서버의 쓰레드 개수는 무슨 근거로 ?
글쓴이: 이원영(javaservice) 2002/02/15 11:38:25 조회수:3192 줄수:65 |
|
>
> {[질문]쓰레드 갯수는 무슨 근거로 정하나요??}
> {울랄라(sugyoo), bulkog@piona.co.kr}
>
>
> 웹로직 5.1에서는 쓰레드 갯수를 정하는 파라미터가 있습니다. 근데요, 이것의 갯수를
> 늘려주고는 싶으나 무엇을 근거로 늘려주는지를 모르겠습니다.
> 참고로 EJB가 200개, 커넥션 풀이 30개입니다.
> CPU 2, MEM 2G
결국, 저의 결론을 말씀드리면, "장애가 없으나 극히 매우 잘 서비스한 상황에서
동시에 서비스하고 있던 Active Thread 의 개수, 그것의 max 치에 준하는 값"으로 마추면
됩니다. 즉, 서로 다른 n개의 응용어플리케이션이 동시에 서비스할 때, 최대의 성능을
나타내는 임계점(Saturation Point)개수로 맞추라는 것이지요.
이 수치를 넘어간다는 것은 이미 계속 요청들어오는 서비스들이 앞으로 지속적인
큐잉현상을 맞이할 것이란 것을 뜻 합니다.
(또 한번 비유를 해 본다면), 일정한 높이를 갖는 깔대기에, 단위시간당 일정한 물을
수도꼭지를 조금씩 틀면서 점차적으로 흘려보내는 실험을 한다고 했을 때,
일정한 시점까지는, 그 깔대기의 물높이는 수도꼭지에서 나오는 물의 량에 비례하여
일정한 수치까지 증가하는 특성을 갖고 있습니다.
그러나, 깔대기 밑을 흘러 내를 수 있는 단위시간당 물의 량보다, 수도꼭지에서 나오는
단위시간당 물의 량이 막 넘어서는 시점부터, 깔대기의 물높이는 지속적으로 순식간에
차 올라와 버리는 특성을 쉽게 연상할 수 있을 것입니다.따라서, 결국, 사실상 필요로
하는 최대의 깔대기 높이는, 단위시간당 흘러내릴 수 있는 최대의 량에 도달하기 직전의
잘 흘러내릴 때의 그 때의 물높이 이면 충분하다는 뜻이 됩니다.
그 이상의 물높이라는 것은, 단위시간당 일정한 량씩 지속적으로 동일하게 흘러 들어오는
실 상황에서는 항상 통계적인 상황에 직면하게 되며, 이 상황에서는 물높이가 해당
시점의 높은 수치에서 고정되어 있는 것이 아니라 지속적으로 높아지고 있다는 것을
뜻하게 됩니다. 만약, 초당 10개씩 밖에 처리하지 못하는 웹사이트에서 초당 12개씩
HIT가 들어온다면, 초당 2개씩 큐잉현상이 일어날 것이며, 10초이면 2*10=20 개의 서비스가
응답을 받지 못하고 큐잉될 것이며, 불과 1분이면 2*60 = 120 개의 서비스가 큐잉될
것입니다. 이는 장애현상, 즉 hang현상에 직면하고 있다는 의미가 됩니다.
(많은 분들이, 충분히 높은 깔대기는 버퍼링효과를 볼 수 있고, 따라서, 버퍼가 클 수록
좋은 것이 아니냐는 생각을 하고 있을 겁니다. 이 가정은 수도꼭지의 물이 나오는
속도가 가변적일 수 있다는 것, 그래서 과도할 땐 비축해 두었다가(Queuing) 적게 나올 때
모아둔 물을 흘러내리게 하겠다는 것이겠지만, 어쨌든 충분히 긴 일정단위시간당 수도꼭지의
방출 속도가 깔대기의 흘러내는 속도를 전체적으로는 넘어서지 말아야 한다는 부분에서는
동일한 제한을 받습니다. 또한, 깔대기의 예가 아니라, 웹기반시스템에서의 실질적인
부하량(workload)의 특징은, 동시단말사용자가 많은 시스템일 수록, 특정시간 근방에서는
항상 일정한 HTTP arrival rate 이 발생합니다.)
그 "충분한 높이"란 것은, 깔대기의 용량과 특성에 따라 항상 다르겠지요? 마찬가지로
웹사이트 마다 항상 서로 달라질 수 밖에 없습니다.
PS: 대부분의 웹사이트에서 100 - 300 이라는 수치를 무조건 맞추는 경향이 있으나, 이는
경험상(!) 대부분 턱없이 불필요하게 높은 수치입니다. 아마도 성능상의 이슈로 인해
장애가 발생하는 사이트에서는 이미 50이상을 넘어서면 순식간에 300까지 차고 올라가는
현상을 목격하고 있을 것입니다. "50보 100보"라는 얘기지요. 이 상황은 특별한 조치가
없는한 절대 복구 되지 않을 것입니다. (NOTE: 언급한 수치는 예일 뿐입니다.)
--------------------
2002.06.04 첨언
자세한 설명은 향후 다시 할 기회가 있을 것으로 생각합니다.
================================================
자바서비스넷 이원영
E-mail: javaservice@hanmail.net
PCS:011-898-7904
================================================
 formula.jpg (28286 Bytes)
|
제목 : Re: 성능이론, 왜 CPU사용률이 높지 않은가?
글쓴이: 이원영(javaservice) 2002/08/22 02:56:10 조회수:1693 줄수:82 |
|
웹어플리케이션서버의 성능장애 유형 중, 왜 대다수가 CPU사용률이 높지 않은가?
웹어플리케이션서버 기반 하에서 운영되고 있는 국내 시스템 장애진단을 경험하다보면,
CPU 사용률이 100%에 다다르면서 장애가 발생하는 경우는 극히 드뭅니다.
CPU사용률이 100%에 이르면서 장애가 일어나는 상황은 일반적으로 다음과 같은 경우가
있을 수 있습니다.
1) 모든 응용어플리케이션들이 매우 잘 튜닝되어 있는(fine-tuned) 상황에서, 동시단말
사용자수 증가로 인한 (상대적) 부하증가(Arrival rate workload increasing)현상이
일어나고, 결국 CPU bottleneck으로 인해 성능저하 및 응답지연현상이 발생하는 경우
입니다.
2) 특정 응용어플리케이션 하나가 CPU bounded-job이고, 이러한 batch성에 가까운
job이 OLPT환경에서 치고 들어올(?) 경우, CPU 사용률이 급정하여, 결국 그동안 잘
운영되던 응용어플리케이션들 마저 제 기능을 수행하지 못하는 경우도 있을 수 있었
습니다.
3) Backend Legacy 연동을 위해 한글변환이나, 데이타 변환과정에서 해당 패키지 코드가
최적의 방법으로 Optimizing 되어 있지 않아, 상대적으로 불필요한 CPU 점유를 가져오는
경우도 있었습니다.
4) 예외적인 경우기는 합니다만, 일종의 어떤 응용어플리케이션버그로 인해, 간단한
block의 무한루프 현상에 빠지게 되어 CPU 100% 현상이 일어나는 경우도 있었습니다.
그러나, 웹어플리케이션서버(Web Applicaiton Server) 기반의 EJB/Servlet/JSP 등과 같은
JAVA언어로 구현된 최근 시스템의 경우는, 웹어플리케이션서버는 process-based로 동작
하는 것이 아니라, (일반적으로) 하나의 process에서 다수의 Multi-thread로 동작하게
됩니다. 또한, Java언어에서는 semapore와 같은 thread locking 기법이 매우 간단하게
구현할 수 있기 때문에, C/C++ 언어에서의 Multi-thread 코딩 기법과 같이 (상대적으로)
전문적인 기술을 가진 개발자의 일정능력을 요구하진 않습니다. 그러다 보니 상대적으로
Java에서의 Multi-thread 구현상에 있어서, 성능을 고려치 않은 자바소스가 양산되는
경향이 있습니다.
국내 수십군데에서의 웹기반 시스템 장애진단 경험에 비추어 보았을 때, 응답이 급격히
느려지는 "서비스큐잉/Hang현상"이 발생할 당시의 시스템의 상황을 보면, 사례의 90%이상이
전부 CPU사용률은 그리 높지 않습니다. 오히려, 장애없이 잘 운영될 때가 더욱 CPU사용률이
높습니다.
어플리케이션 리소스 bottleneck이라는 얘기지요. 마치 DB lock 이 발생하면, 모든 요청이
큐에 대기하게 되고, 결국 실제 processing 하고 있는 서비스 Job의 개수는 많지 않으니 CPU
사용률은 오히려 낮을 수 밖에 없다는 것을 예로 들 수 있습니다.
응용어플리케이션 내에 존재하는 synchronized 키워드를 남발하는 경우도 있을 수 있습니다.
성능적인 측면에서 다양한 경험이 있는 개발자의 조언이 반드시 필요한 부분인 것이지요.
또한, HOST의 CICS 트렌젝션을 사용하기 위해 CTG(CICS Transaction Gateway) API를 이용하여
접근하게 되는데, 이 부분에 대한 Java측의 코딩이 성능을 고려하여 smart하게 되어 있지
않을 경우, 유사한 상황에 직면할 수도 있습니다. 울산 모 고객사의 경우를 대표적인 예로
들수 있습니다. CTG API중 실질적인 communication 을 담당하고 있는 JavaGateway 인스턴스를
서로 다른 요청에 대해 공유하고 있다거나, 혹은 JavaGateway를 통한 통신상의 성능향상을
위해 JavaGateway Pool를 사용하고 있을 수도 있는데, 이 역시, Multu-thread환경에 익숙한
개발자에 의해 검증되어야 할 것입니다.
거듭 강조하지만, 경험적으로, 성능상의 이유로 장애상황이 발생하면 CPU사율률은 높지
않는 것이 일반적인 현상입니다. CPU 100%가 올라가면서 장애가 일어나는 경우는 오히려
매우 고무적인 상황이며 CPU만 추가하면 해결되는 문제이기도 합니다. 그러나, 이런 경우는
아쉽게도 극히 드문현상입니다.
이러한 현상을 C/S 시스템의 장애해결에 익숙한 분들은 쉽게 받아들이지 않으시더군요.
Client/Server환경에서는 대부분이 process 기반의 프로그램들이 대부분이었고, 사용자
증가는 곧바로 독립된 process의 CPU사용증가를 가져왔기 때문에, 상대적으로 C/S환경에서는
CPU bottleneck에 의한 현상이 대표적이었을 것입니다.
무엇보다 중요한 것은, 업무적차원에서 추정할 수 있는 최대 동시단말사용자수와 최근
며칠동안 (비록 장애상황에 직면하였지만) 모니터링된 웹로그분석을 기반으로 실제 발생
하고 있는 부하량(workload)를 측정하고 모델링하여 성능테스트(BenchmarkTest)를
시행하고, 종합적인 관점에서의 성능진단작업이 반드시 필요합니다.
PS: 일련의 경험을 통해 깨닫게 된 사실은, 부하량/성능모델링 관점에서의 CPU자원은
N/W용량이나 WorkerThread의 개수 혹은 Disk I/O, Backend System Connectivity 혹은
응용어플리케이션의 Over Locking(과도한 synchronization 혹은 Transaction Lock) 등과
마찬가지로, Bottleneck을 유발하는 하나의 큐(Queue)일 뿐이라는 것입니다. n개의 서로
다른 응용어플리케이션들에 대한 서로 다른 호출빈도(arrival rate)와 각 응용
어플리케이션들의 최대 Throughput들을 n차원 유클리드공간상에서 표현했을 때, 병목을
유발하는 다수의 큐(Multiple Queue)들에 의한 임계성능평면(가칭)이 결정되고, 이러한
각 평면이 만나 일련의 병목경계면을 형성하게 된다는 [다중병목임계면이론(가칭)]을,
큐잉이론(Queuing Theory)를 응용하여 고민하는 중인데, 이러한 관점에서 보면, CPU에
의한 병목은 최근의 J2EE기반의 웹어플리케이션서버 환경하에서는 상대적으로 잘 도출되지
않습니다. CPU가 병목으로 나타나기 이전에, 다른 병목임계평면과 먼저 직면하기
때문입니다.
자바서비스넷 이원영
|
제목 : Re: Synchronized 블럭 성능의 수치적 해석
글쓴이: 이원영(javaservice) 2002/09/16 06:57:20 조회수:1857 줄수:188 |
|
> 제목: 안녕하십니까? 감히 질문이 있어 여쭙니다.
> 보낸날짜 2002년 09월 10일 화요일, 새벽 03시 21분 08초 +0900
> 보낸이 "ByoungOkLee" <leebyoungok@hotmail.com>
> 받는이 <javaservice@hanmail.net>
>
> 안녕하십니까?
> JavaServerNet에서 많은 자료를 얻어면서 과장님의 체계적이고 폭넓은 지식에 감탄을
> 금할 수가 없습니다. ....(생략)....이지 시스템에 다니고 있는 이병옥 이라고 합니다.
> ...(생략).... 제 짧은 소견에 대한 평을 듣고 싶어 이렇게 불쑥 메일을 여쭙니다.
>
> 개인적으로 JT400의 AS400 Connection을 이용한 Pool을 설계하고 또 사용하고 있는데,
> 한가지 딜레마가 생깁니다. 일반적으로 Pool로 부터 자원을 확보하는 메소드에
> synchronized를 걸어 직렬화를 시키는데, 이렇게 했을경우 Dead Lock 현상도 발생하지
> 않고 좋아 보이지만, AK Tool 같은 스트레스 툴로 동시에 다수개의 Thread를 발생시킬
> 경우 각각의 Thread가 자원확보를 위해 Pool에 와서 한줄로 늘어서게 되는 현상이 발생
> 할 줄로 판단됩니다.
> 실제 AS400 Connection으로 RPG를 호출하는데 Pool을 이용했을경우 자원획득을 위해
> AK Tool에서 발생시킨 Thread가 직렬화 되는 현상을 보여 오히려 전체 Response Time이
> 느려지는 현상을 겪었습니다. 또한 RPG의 Response Time이 워낙 빨라 스트레스를 아무리
> 많이 줘도 Pool에서 2~3개의 자원만으로 처리가 이루어 집니다.
> 실제 보다 많은 다중 Thread로 처리되었을 경우 훨씬 빨리 처리가 가능하나 직렬화로
> 인하여 피해를 보는 셈이 되는 것이죠.
>
> Pool의 장점인 자원 재사용을 한다고는 하지만, 이러한 상황에서 스트레스 테스트가
> 의미가 있는것인지가 궁금합니다.
>
> 아울러 Web Sphere같은 WAS 계열에서는 이러한 문제점의 해결책으로 어떤 방안을
> 일반적으로 취하는지도 궁금합니다. 개인적으로 Pool의 개수를 복수개로 운영하여
> Multi Thread에 가변적으로 대응하는 방법은 어떨지도 고민중입니다.
>
> 누구보다 바쁘신줄 알지만, 과장님 시간이 허락하신다면 과장님의 소견을 듣고 싶습니다.
>
> 이지시스템 이병옥 드림.
===============================================================================
많은 사람들이 잘못 생각하고 있는 부분이 Connection Pool의 getInstance(),
getPooledObject() 류의 메소드가 synchronized 되어 있기 때문에, 한순간에 하나씩
처리되어 전체적으로 "성능"이 떨어진다고 쉽게 단정한다는 것입니다.
synchronized 는 필요할 때 적절히, "반드시" 사용되어야만 하는 것입니다.
"아무리 부하를 주어도, RPG는 2-3 개 밖에 running하고 있지 않다"는 것은 많은 것을
시사하고 있습니다. 분명 RPG 호출로 인한 backend 서비스는 현재의 성능저하와는
다소 거리가 있다는 것은 분명합니다. 그렇다면 어디일 것인가를 찾아야 하는데, 그 한
예로써, Pool에서 Pooled Object를 꺼내오는 synchronized getPooledObject()류의
메소드를 의심해 보는 것은 자연스럽기는 합니다. 해당 블럭의 구현을 얼마나 간결하고
핵심적으로 코딩하였느냐가 관건이지요.
최근 찾아낸 수식을 제 머리속에만 간직하고 있다가, 저 아닌 다른 분에게는 오늘
처음으로 몇자 적어봅니다.
synchronzied block S 가 있을 때, 해당 구간에 대한 단일요청에 따른 응답속도(Elapsed
Time)가 s (sec)라고 했을 때, 해당 구간에 대한 최대 Throughput은 1/s (request/sec)가
됨을 쉽게 추론할 수 있습니다.
synchronized 되어 있으므로, 해당 구간의 소요시간이 1 ms 라면 해당 구간으로 인한
Throughput은 최대 1000 tps가 될 것이고, 해당 구간에서 100 ms가 절대적으로 소요된다면
최대 10 tps가 될 수 있겠지요.
반면, synchronized가 걸려있지 않은 적어도 1/s (request/sec)보다는 클 것입니다. 이는
해당 block의 bottleneck으로 작용하는 resource에 따라 달라지는 것이지요. bottleneck으로
작용하는 resource라는 것은 CPU,Backend Service(RPG처럼), Worker-Thread의 개수,
Pool의 최대개수, 응용어플리케이션의 over-locking 구간 등등이 모두 Bottleneck의
원인일 수 있으며, 이를 큐잉이론 관점에서 보면 모두 한계(boundary)를 갖고 있는
"One of Queue"라는 것입니다.
프로그래밍 소스 블럭 A 및 B 구간이 있다고 가정하고,각 블럭A, B 구간의 각각의 단위시간당
최대처리건수인 최대 Throughput이 각각 10 tps, 20 tps(transaction per second)라고
합시다. 만약, 블럭 A,B구간을 같은 소스에 순차적으로 넣고 최대 Throughput을 측정하면
최대로 얼마가 나올까요?
case 1 : 10 tps
----------------
program block A
----------------
case 2: 20 tps
----------------
program block B
----------------
case 3: ? tps
----------------
program block A
program block B
----------------
답은 ,
1 10*20
----------- = ------- = 6.6666 tps 가 됩니다.
1 1 10 + 20
--- + ---
10 20
다음과 같은 공식입니다.
1
(Throughput of block A & B) = -----------
1 1
--- + ---
a b
(위 수식은, 차후에 다시 자세히 증명할 기회가 있을 겁니다.)
A구간이 최대 10 tps였으니, 로직B가 추가되면 전체는 최소한 10tps보다는 작을 것이고,
마찬가지로 구간B의 최대 tps인 20 tps보다도 작을 것입니다.
만약, 특정 구간 B의 Throughput b가 상대적으로 A구간의 Throughput a에 비해 tps가
엄청나게 크다면, 두 구간을 합한 tps는 구간A의 최대TPS a에 매우 가까울 것입니다.
왜냐면, 1/b 에서 b값이 상대적으로 100, 1000, 10000 등과 같은 수치일 경우 위 수식은
a 에 가까운 수치가 될 것이잖습니까?
예) 구간 A,B에 대한 각각의 Throughput이 각각 5 tps, 1000 tps일 때, 구간A,B를
순차적으로 하나의 블럭으로 만든다면, 최대 몇 tps가 나올 수 있을까요?
1 / {1/5 + 1/1000} = (5*1000)/(5+1000) = 4.975 tps
무슨 얘기를 하고자 하는 것이냐면, ConnectionPool에서 synchronized로 되어 있는
getInstance(), getPooledObject() 부분의 throughput은 (경우에 따라 다르겠지만)
응용어플리케이션의 throughput에 비해 상대적으로 매우 큰 수치입니다. (상대적으로)
매우 짧은 순간만 해당 부분을 타는 것이지요. (사실 중요한 것은 "그 짧은 순간"이
얼마나 짧으냐가 중요합니다. synchronized된 해당 구간의 Throughput은 1/(그짧은순간)
이라는 절대적인 Throughput으로 나타나기 때문입니다.)
따라서, synchronized 블럭의 Throughput이 상대적으로 응용어플리케이션의 Throughput보다
충분히 크면, 해당 synchronized 블럭으로 인한 성능저하는 (상대적으로) 적을 수 있다는
것입니다. (PooledObject를 Pool에서 꺼내오는 부분은, 단지 가용한 Reference를 꺼내오는
것이 전부일 것이며, 해당 구간의 Throughput은 "충분히" 문제시 되지 않을 수 있습니다.)
PS: 질문하신 분의 상황은, 보내주신 글만으로는 판단할 수 없습니다.
소스를 열어보고, 예상되는 성능저하구간을 설정한 뒤, 스트레스테스트를 통해 어느
부분에서 가장 성능이 저하되는 지를 찾아보아야 합니다. 현재로서는 getPooledObject()
그 자체일 수도 있으나, 일단 꺼내온 뒤, RPG를 실제 호출하기 전 초기화 작업이나,
호출 이후의 데이타 파싱을 위한 구간일 가능성도 배제할 순 없습니다.
설령 getPooledObject() 부분에서 많은 시간이 소요된다면, 그 자체가 문제가 아니라,
응용어플리케이션이 PooledObject를 Pool에서 꺼내간 후, 오랫동안 해당 자원을 사용하기
때문일 수도 있습니다. 물론, synchronized가 걸려 있는 블럭에서, 불필요한 잡다한
작업을 넣어 compact하지 않은 코딩을 했을 가능성을 배제할 수 없습니다. 해당 부분은
적어도 위와 같은 이론적 이해를 바탕으로 해당 사이트의 부하량과 H/W용량 및 S/W의
Throughput을 고려하여 설계->코딩->스트레스테스팅->튜닝 과정을 거쳐 반드시 검증되어야
하는 것은 당연합니다. Performance Analysis는 "종합예술"이잖습니까.
-------------------
2004.05.13일 추가
> 쓰레드를 시작할때의 오버헤드가 미리 생성된 쓰레드가 작업을 대기하고 있을 때
> 발생하는 오버헤드보다 "그리 크지 않다".
"그리 크지 않다"는 용어는 상대적으로 해석해야 합니다. 예를 들어, 다소 무거운
어플리케이션이 있고, 일정 규모의 H/W에서 CPU 100% 가용도 상황에서, Thread Pool로
구현한 것이 1초당 50 tps(transaction per second)를 성능을 처리하는 반면,
매번 Thread를 start() 시키는 구조의 경우는 48 tps가 나오더라고 가정해 보겠습니다.
이 경우, 우리는 "그리 크지 않다"는 판단을 할 수도 있겠습니다.
만약, 어플리케이션로직이 이번엔 매우 가벼워서, Thread pool로 구현한 구조의 경우
자그마치 1,000 tps가 나온다면, 만약 이를 매번 thread start() 시키는 구조로 변경했을
때, 몇 tps로 떨어질까요? 저의 이론에 의하면, 이는 545 tps로 떨어지게 됩니다.
즉, 항상 상대적으로, 어떠한 경우에 크다/크지않다라는 단서가 붙게 된다는 것이지요.
[증명]
x : thread pool을 이용할 때의 thread pooing 자체의 성능(tps)
y : thread pool을 이용하지 않고, 매번 thread.start() 시키는 방식의 해당 성능(tps)
A : 해당 무거운 어플리케이션 로직부분만의 성능
B : 가벼운 어플리케이션 로직부분만의 성능
여기서, 다음과 같은 식이 도출됨.
50 = 1/{1/x + 1/A}
48 = 1/{1/y + 1/A}
1000 = 1/{1/x + 1/B}
우리가 구하고자 하는 것은, 1/{1/y + 1/B}의 값입니다.
위 식에서, 1/a = a' 이라고 한다면,
50 = 1/(x' + A') --> A' = 1/50 - x'
48 = 1/(y' + A') --> y' = 1/48 - A' = 1/48 - {1/50 - x'}
1000 = 1/(x' + B') --> B' = 1/1000 - x'
따라서, 1/(y' + B') = 1/{ (1/48 - 1/50 + x') + (1/1000 - x')}
= 1/{ 1/48 - 1/50 + 1/1000 }
= 545.5 tps
-------------------------------------------------------
본 문서는 자유롭게 배포/복사 할 수 있으나 반드시
이 문서의 저자에 대한 언급을 삭제하시면 안됩니다
================================================
자바서비스넷 이원영
E-mail: javaservice@hanmail.net
PCS:011-898-7904
================================================
ThroughputFomula.jpg (33894 Bytes)
|
제목 : Re: synchronized 블록 내 로직 수행시간의 중요성
글쓴이: 차의중(prof21) 2002/09/18 15:10:31 조회수:1090 줄수:46 |
|
퍼포먼스 튜닝 관련한 문서에서 항상 언급하고 있는 것 중의 하나가 synchronized 입니다.
synchronized 블록으로 스레드가 진입할 시, 모니터를 획득하기 위해 소요되는 시간도
적지 않거니와 무엇보다도 하나의 스레드가 synchronized 블록을 빠져나오기까지 다른
스레드는 그 곳에서 대기해야 하기 때문이지요.
이 중, 모니터를 얻기위해 소요되는 CPU자원은 요즘의 CPU의 빠르기를 감안하고, 또한,
일반적인 시스템 내에서 일어나는 다른 작업,
예를 들어, 데이터의 삽입, 수정, 검색등과 비교한다면 그야말로 매우 미미하여 사실상은
무시해도 상관이 없을 정도입니다.(물론, 수억, 수십억번 이상의 산술적인 계산등을
반복적으로 행하는 주로 자연과학이나 공학계산용의 어플리케이션에서라면 이러한 작은
시간도 매우 중요하겠죠.)
그렇다면 정말 문제가 될 수 있는 것은 synchronized 블럭으로 인해 발생하는 스레드들의
대기(큐잉)현상일것입니다. 그런데, 여기에서의 스레드 직렬화 즉, 큐잉현상으로 인해
이 지점이 병목의 주된 원인이 되기 위해서는, 이 블록 내에서 실행되는 로직의 처리시간이
다른 어떤 큐잉가능 블록의 처리시간보다도 길어야 합니다.
보통, 커넥션 풀에서 커넥션을 얻어오는 로직(getConnection())은 synchronized 블록으로
묶여있습니다. 그런데, 커넥션 풀에서 커넥션을 얻어와서 리턴해주는 로직이 소요되는
시간이 얼마나 될까요? 이 또한, CPU의 클럭 속도와, 메모리와 CPU간의 데이터 교환 속도,
교환되는 바이트 수를 생각하고, 또한 시스템 내의 다른 로직과 비교했을 때 엄청나게
미미하여, 거의 신경을 안써도 될 정도입니다. 여러분은 1초 내에 수천 혹은 수만 번
이상의 getConnection()을 실행시킬 수 있습니다.
만일, getConnection()의 throughput 이 10000TPS 라면, 10000TPS 미만의 throughput을
가진 로직이 있지는 않을까를 생각해보십시요. 그런 부분이 있다면, 그 부분을 먼저
개선시켜서 10000TPS 이상의 스루풋을 갖게 한 후에, getConnection()의 수행성능 향상을
고려해보시기 바랍니다.
그러나, 대부분의 데이터 처리 로직(대표적인 것이 데이터베이스에 대한 질의입니다.)
은 아무리 해도 이만큼의 throughput을 보장할 수 없을 것입니다. 따라서,
getConnection()에서 사용되는 sychronized 블록은 병목의 용의자 선상에서 아예
제외시키는 것이 정신건강(?)에 좋을것입니다.
ps : 실제로, synchronized 블록은 시스템 내에서 엄청나게 많이 사용됩니다. 아무
생각없이 사용하실 지 모를 Vector 나 Hashtable 을 열어보십시요. 셀 수 없이 많은
synchronized 블록이 있는 것을 보실 수 있을 것입니다. 기억하십시요. sychronized
블록의 사용 자체가 문제가 아니라, synchronized 블록 내에서 실행되는 로직의
수행시간만이 문제가 될 수있다는 것을!!
-----------------------------------------------------------------
본 문서 및 첨부파일은 자유로이 복사/배포가 가능하나 반드시 저자의
이름과 연락처를 명시해주시기 바랍니다.
차의중
prof21@empal.com
|
제목 : Re: Multiple Bottleneck Queue Surface
글쓴이: 이원영(javaservice) 2002/09/19 06:33:11 조회수:945 줄수:20 |
|
제목 : Re: 웹퍼포먼스 포럼: 성능에 관한 수치해석적 접근
글쓴이: 이원영(javaservice) 2002/09/30 15:05:41 조회수:1407 줄수:46 |
|
웹기반시스템하에서의 성능에 관한 수치해석적 접근
일시: 2002.09.30
Topic:
1. Throughput Formula
2. Concurrent User
3. Multiple Bottleneck Saturation Surface Theory
4. # of parameter for best performance
5. Service Level Specification,
- Maximum User & Response Time
토론회 참석자:
고규백 - 우노시스템, 기술지원부 System Engineer
김균홍 - LGCNS ITG 인프라스트럭쳐팀 대리
김대중 - BEA 컨설팅 담당 : Performance tuning과 개발 경험 보유
김문회(불참) - 건국대학교 실시간시스템공학연구실 부교수
김범수 - MI(Mercury Interactive)사 Senior SE 부장
김봉준 - 자바개발자(아마추어참관)
김성진 - LGCNS 기술연구부분, 인프라스트럭쳐님 대리
김풍주(불참) - 현대정보기술
박성훈 - 코오롱정보통신, 스트레스테스팅 경험기술보유
박용우 - 펜타시스템테크놀러지 고등기술연구소 선임연구원
박종빈 - 삼성SDS 프로젝트오피스팀 첨단S/W공학센터 과장
손정민(외1명) - 티맥스소프트 미들웨어기술지원, R&D
양병국 - 한국볼랜드
옥상훈(絶對高手)과장 - 자바크래프트닷넷, CPU용량 산정 기준
윤돈경(불참)- LGCNS 기술연구소, 웹기반시스템 개발 통합팀장
윤정태 - LGCNS 연구개발센터 기술내재화팀 대리
이아스(이창신) - 독립 개발 연구 저술 강연자,JSR J2ME Expert Group
이원영 - 자바서비스넷 기술커뮤너티 대표, Performance/PD 전문가
장형근 - 개발경력 2년(아마추어참관)
차의중 - 스펜오컴 소프트웨팀,자바서비스넷 운영자,PowerTier,J2EE전문가
허광남 - okjsp.pe.kr
====================================================
2002.10.24 웹퍼포먼스이론관련 주제는 아래의 문서에서 계속 이어지고 있습니다.
590 웹퍼포먼스이론: 실사이트 측정결과보고서 및 관련언급
http://www.javaservice.net/~java/bbs/read.cgi?m=qna&b=consult&c=r_p&n=1035524021
PerformanceAnalysis_jsc_20050510.zip (1535432 Bytes)
 DiscusstionForPerformanceConceptAnalysis.ppt (742912 Bytes)
 MathematicalApproachToPerformance.pdf (274159 Bytes)
|
|
PS: 짜릿하지 않나요?
-------------------------------------------------------
본 문서는 자유롭게 배포/복사 할 수 있으나 반드시
이 문서의 저자에 대한 언급을 삭제하시면 안됩니다
================================================
자바서비스넷 이원영
E-mail: javaservice@hanmail.net
PCS:011-898-7904
================================================