Hibernate performance tuning
View more presentations from SanderMak.
신고

'Programming > Hibernate' 카테고리의 다른 글

Hibernate Performance  (0) 2010.12.15
by Hazard 2010.12.15 09:32

내가 이걸 왜 보고있는지는 모르겠지만, 유용한덧.
http://developer.apple.com/library/ios
-hazard-
신고
by Hazard 2010.11.18 13:53

오늘 테스트에 참여해주신 렌즈입니다.





1. 니콘 50mm F1.4






2. 니콘 50mm F1.8
   GF1용 어댑터가 붙어서 길어보이긴 하네요





50mm F1.4 iso200 1/50





50mm F1.8 iso200 1/25




결론
. 점팔이와 점사는 가격은 4배차이지만 비슷한 수준의 아웃 포커싱을 보여준다. 아웃 포커싱을 위해서라면 업글 의미 없음
. 점팔이 보다 점사는 같은 조건에서 조리개 최대 개방시 1스텝정도의 셔터스피드를 확보해준다. 실내용으로는 훨 좋은듯.
. 점사는 최대개방에서 아주 조금 선예도가 떨어진다. (위의 사진은 점사 안에 이물질이 있는것으로 보여 좀더 흐려보임)





-hazard-





신고
by Hazard 2010.11.08 20:33

신고

'Programming > Phone' 카테고리의 다른 글

How to add Adsense to jQuery mobile page.  (0) 2012.08.22
iOS Reference Library  (0) 2010.11.18
갤럭시S 출시  (0) 2010.06.08
아이패드(iPad) 태고의 달인 맥스봉 버전  (0) 2010.06.08
iPhone 4G 소개 동영상 (아이폰 4세대)  (0) 2010.06.08
iPhone Durex baby  (0) 2010.06.04
by Hazard 2010.06.08 11:20

신나보이네요 ㅎ



신고

'Programming > Phone' 카테고리의 다른 글

iOS Reference Library  (0) 2010.11.18
갤럭시S 출시  (0) 2010.06.08
아이패드(iPad) 태고의 달인 맥스봉 버전  (0) 2010.06.08
iPhone 4G 소개 동영상 (아이폰 4세대)  (0) 2010.06.08
iPhone Durex baby  (0) 2010.06.04
아이폰 Tip 단축키 모음  (0) 2010.01.14
by Hazard 2010.06.08 10:55
드디어 올것이 왔습니다.

갠춘하네요 :)





신고
by Hazard 2010.06.08 08:36

이건 좀... 다마고치 인가요?
신고
by Hazard 2010.06.04 08:27
Lean production
(Lean)이라는 단어의 사전적 의미를 보게되면 Without much flesh , (of meat)with little or no fat, 여윈기름기가 없이살코기만의라는 뜻으로 해석된다 생산방식(Lean production)이라는 것은 미국의 MIT(매사추세츠 공과 대학) 연구그룹이 1990 도요타생산방식으로 대표되는 일본식 생산시스템에 붙인 이름이다 생산방식이란 생산현장의 원자재와 재공품의흐름을 분석하고 제조설비의 배치를 최적화해 중소제조업체의 생산성을 20%이상 높여주는 기법이다.
 생산은 세계적 수준에 이른 반복공정으로써 시간을 중요시하는 새로운 반복공정 생산시스템이다2 세계대전  일본의도요타와 오노가  생산의 개념을 가장먼저 개척하였다 생산은 일본의 자동차산업에서 가장 많이   있지만세계 곳곳에 퍼져많은 자동차회사들이  생산을 도입하였다.
 생산방식은 수공업생산방식과 대량생산방식의 장점을 결합한 것으로서 수공업생산방식에서 오는 원가상승  대량생산방식의융통성 부족 문제를 극복한다이렇게 하기 위하여  생산방식에서는 조직의 모든 부문에서 다능공(多能工팀을 편성하여 융통성 있는 자동화기계를 사용하여 매우 다양한 제품을 적정량씩 생산한다.
 생산방식은 대량생산방식에 비해 '작은(lean)' 것이다. (lean production 이라는 용어는 IMVP 연구자인 John Krafcik만들었음.) 공장에서 필요한 노동력생산에 필요한 면적공작기계 투자액신제품개발 소요시간이 절반에 지나지 않는다더욱이  생산방식에서 필요한 재고는 대량생산방식의 절반에 훨씬  미치면서도 결점수는 대폭 감소되며 점점 더욱 다양한 제품을생산하는 것이다.
 
Lean 생산 방식의 Agile 적용 – Lean Software Development 7가지 원칙
 
1.    낭비를 제거하라
고객을 위한 가치를 창조하지 않는 모든 것은 낭비다
낭비 제거는 가장 기본적인  원칙이며다른 모든 원칙은  원칙에 바탕을 두고 있다그러므로  개발을 수행하는  번째단계는 낭비를 찾는 법을 배우는 것이고 번째는 낭비가 발생하는 가장  이유를 찾아내고이를 제거하는 것이며 다음 단계는 아직 낭비 요소가 남은 원인을 찾아내고 낭비를 제거하는 것이며이후에 이를 반복한다
 
l  미완성 작업
완성되지 않은 소프트웨어는 그대로 사장될 위험이 크고다른 개발 작업에 방해가  수도 있다그러나 그보다  문제는 결국 그것이 사용될지 안될지  수가 없다는 사실이다.
l  가외 프로세스
문서 작업은 자원을 소비하고 결과를 내는데 시간이 걸리게 만들  아니라 품질 문제를 숨기고 그다지 보람도 없으면서갈수록 쓸모가 없어진다아무도 읽으려 하지 않는 문서 작업은 가치를 부가하지 않는다어떤 문서 작업이 가치 있는지를 확인하는 가장 좋은 방법은 그것이 만들어지기를 기다리는 사람이 있는지 확인하는 것이다.
l  가외 기능
이것은 위험을 야기할 수도 있으며 심각한 시간 낭비다시스템의 모든 코드는 수정될 때마다 추적컴파일통합테스트되어야 하고전체 시스템의 일부로 유지되어야 한다코드의   줄은 시스템의 복잡도를 높이고 잠재적인 결함 요소를 가진다.
l  직무 전환
 사람을 여러 프로젝트에 투입하는 것은 낭비의 근원이다소프트웨어 개발자가 프로젝트를 전환하려면생각을 모으고 새로운 작업 흐름에 익숙해지기 까지 매번 상당한 시간을 필요로 한다여러 팀에 속하는 것은  많은 중단과  많은 업무 변경을 야기한다이러한 직무 전환 시간은 낭비다.
l  대기
어떤 일이 일어나기를 기다리 것은  낭비다프로젝트 시작  지연인원 구성의 지연과도한 요구사항 문서 작업으로 인한 지연검토와 고객 승인  생기는 지연테스트에서의 지연배포에서의 지연은 모두 낭비다.
l  이동
개발은 집중을 요구하는 활동이므로 층을 이동하게 되면 생각보다 훨씬 많은 시간이 걸린다질문에 답을 얻는데 걸린시간보다 개발자가 다시 집중하는데 걸리는 시간이     것이다애자일 소프트웨어 개발에서 개발자테스트 담당자고객  관련된 모든 사람이 하나의 작업 공간에서 작업하도록 권장하는 이유가 여기에 있다.
l  결함
결함 때문에 발생하는 낭비는 발견되기까지 걸린 시간과 결함의 파급력에 비례한다결함으로 인한 낭비를 감소시키려면 즉시 테스트하고 자주 통합하고 가능한 빨리 완성하여 릴리즈 하는 것이 좋다
 
 
2.    배움을 증폭하라
l  소프트웨어 개발에서의 품질
소프트웨어 개발에서 품질은 인식 통합성과 개념 통합성  차원에서 생각   있다인식 통합성이란 제품이 기능,사용성신뢰성경제성  전체적인 면에서 균형을 이루어 고객을 만족시킨다는 의미다반면 개념 통합성이란 시스템의 중심 개념이 유연하면서 응집력 있게  작동한다는 의미다.
l  소프트웨어 개발에 관한  가지 주장
하나는 처음부터 모든 설계와 코드가 완벽해야 한다고 개발자들이 확신하도록 독려하는 것이다다른 하나는 설계와 코드가 처음부터 정확하도록 하는 것보다는 소규모로 신속하게 빌드하는 사이클을 만드는 편이  좋다는 것이다처음부터 제대로 신중한 검토를 하고 진행하는 접근법은 구조화가   문제에는 좋지만 구조화되지 않은 문제에는 대게신속한 빌드하는 접근방법이 좋을 것이며 테스팅 비용이 매우 높다면 신중한 검토를 통해 지식을 얻는 편이 나을 것이다.
l  학습주기
리팩토링을 수반한 반복 시스템을 개발해 가면서 설계를 개선하는 방법은 지식을 생성하고조기에 해답을 찾고통합성 있는 시스템을 만드는 가장 효과적인 방법  하나라고 밝혀졌다그것은 이러한 접근법이 문제가 잘못 정의된 경우에 가장 효과적으로 지식을 생성하기 때문이다개발에서 가장 중요한 질문은 어떻게 해야 가장 효과적으로 배울 있는가?” 이고 대답은 짧은 학습 주기를 여러  거치면 된다는 것이다.
l  피드백
대부분의 상황에서 소프트웨어 개발 프로젝트가 문제에 부딪힐  환경을 개선하는 가장 효과적인 방법은 피드백을 줄이는 것이 아니라 늘리는 것이다.
n  결함을 쌓아두지 말고 코드를 작성하는 대로 바로 테스트하라
n  문서나 상세계획서를  만들지 말고코드를 작성해서 아이디어를 확인하도록 시도하라
n  사용자에게서 요구사항을  모으지 말고나중에 사용하게  사용자 화면   가지를 보여주고 의견을 수집하라.
n  사용할 도구를 고르는  너무 많은 노력을 들이지 말고현재 도구 가운데 제일 나은  개를 골라 테스트해 보라
n  한번에 전체 시스템을 바꿀 방법을 찾으려 애쓰지 말고기존 시스템에  기반의 화면을 만들어 여기에서 새로운 아이디어를 얻도록 노력 하라
개발자는 그들의 직접적인 고객이 누구인지와 그들에게 정기적인 피드백을 제공하는 방법을 알아야 한다문제가 발견되면 제일 먼저  일은 피드백 루프가 모두 완전한지 확인하는 것이다 말은 자신의 직접적인 고객이 누구인지 모두알아야 한다는 의미다.
l  반복(Iterations)
반복이란 짤게 정해진 기간 내에 설계프로그램테스트통합배포하여 소프트웨어의 유용성을 증가시키는 것을 말한다이것은 최종 제품의 일부로 실제 사용된다는 사실을 제외하고는 제품 개발 과정에서 만드는 프로토타입과 매우 유사하다 소프트웨어는 향후의 계속적인 반복을 통해 개선되기는 하지만처음 만들어질 때부터 작동되는 테스트를 거친통합된 코드다.
반복은 순차적 소프트웨어 개발에서 엄청난 피드백을 발생시키므로 고객과 개발자  시스템에 관심 있는 다양한 사람들 간에 훨씬 폭넓은 의사소통을 가능하게 한다.
 
 반복의 3가지 원칙
n  작은 단위 작업은 자원 활용도를 높임으로써 작업자 사이의 의사소통을 향상시키고 품질을 높인다작은 단위의 작업은 피드백 루프가 짧아서 다루기가 쉽다.
n  반복 주기가 짧아지면시스템은 예측보다 사실에  반응하게 된다.
n  반복은 작업자 개인이나 여러 팀과 고객 간의 의견을 동기화하는 접점이다반복은 기능을 완성하여 시스템을 릴리즈또는 선적할  있는 상태가  바로  지점이다.
 
 반복 주기의 초기에는 개발팀이 개발할 기능들의 난이도를 추정하고고객이나 고객 대표로 하여금 예상 비용을 감안하여 기능의 우선순위를 결정하게 하는 계획 세션을 수행한다가장 높은 비즈니스 가치를 먼저 제공하려면 가장 중요한기능을 먼저 개발해야 한다위험성이 높은 항목들도 나중으로 미루지 말고 일찍 시작하는 것이 좋다
 
 
3.    가능한 늦게 결정하라
l  동시 소프트웨어 개발
n  깊이 우선 접근법은 상위 수준의 의사결정을 하위 수준에 의존하게끔 만든다손실이 가장  실수는 시작할 중요한 부분을 고려하지 않아서 빚어진다 실수는 구체적인 사항으로 너무 빨리 진행할  발생하기쉽다일단 세부적인 경로를 정하고 나면되돌릴  없으며  사실을 깨닫지 못하는 경우가 많다 실수가 발생할 가능성이 있을  가장 좋은 방법은 계획 전반을 둘러보고 구체적인 결정을 미루는 것이다.
n  동시 개발  너비 우선 접근법을 채택하면 크고 비용이 많이 드는 문제를 너무 늦기 전에 발견할  있다.순차 개발 방식(깊이 우선)에서 동시 개발로 이동한다는 것은 상위 단계의 개념적 설계가 결정되면 비록구체적인 요구 조건들이 아직 조사 단계라 할지라도바로 가장 높은 가치가 있는 기능을 프로그래밍하기시작하는 것이다이것은 직관에 반하는 것처럼 들릴지도 모른다하지만  방법을  중요한 기능들의구현을 강요하는 방향으로 쫓아 가기 전에 , 여러 가지 다양한 선택을 시도하면서 배워 나갈  있게 해주는 탐색적 접근이다.
 
l  비용상승
순차 개발은 모든 결정을 가능한 빨리 내릴 것을 강조한다그러면 모든 변경 비용은 동일하게 매우 높다동시설계는 결정을 가능한  미룬다 이것은  가지 효과가 있다.
-      비용이  제약 조건의 수를 줄인다.
-      비용이  결정 사항을 너비 우선 방식으로 처리하면 좀더 바람직하게 결정할  있다.
-      대부분의 결정을 이뤄둔다특히 변화의 필요를 줄여준다.
-      대부분의 변화에서 비용 증가 요소를 급격하게 감소시킨다.
 소프트웨어 개발은 모든 설계에 대한 확정을 가능한 지연시킨다아직 확정되지 않은 결정은 변화시키기 쉽기 때문이다 소프트웨어 개발에서는 설계를 강건하고 변화에 유연하도록 개발하라고 강조한다 설계방식은 불가피한 변화를 받아들이고 여러 종류의 변화에 손쉽게 적응할  있도록 시스템을 구성한다.
 
l  책임이 따르는 마지막 순간
동시 개발은 결정을 책임이 따르는 마지막 순간” 결정하지 모해 중요한 대안이 제거되기 직전까지 결정을미루는 것을 가능하게 해준다마지막 순간으로 결정을 미루는  가지 팁이 있다.
 
n  부분적으로 완료된 설계 정보를 공유하라.
설계가 릴리즈되기 전에 완전해야 한다는 관념은 동시 개발의 가장  적이다.
n  작업자들  직접 협력 체계를 구성하라
구체적인 사항을 이해하는 사람들과 반드시 직접 의사소통 해야 한다.
n  변화를 수용하는 방법에 대한 감각을 개발하라.
객체지향 설계와 컴포넌트 기반 개발 기법을 사용하라.
-       모듈을 사용하라 : 인터페이스에 대한 고객의 요구사항이 안정될 때까지 모듈의 내부 설계 결정을 미루어라.
-       인터페이스를 사용하라 : 구현과 인터페이스를 분리하라구현은 변하더라도고객에게 제공되는 인터페이스는 동일하게 유지하라.
-       매개변수를 사용하라.
-       추상화 기법을 사용하라
-       순차 프로그래밍을 피하라 : 절차적 프로그래밍이 아닌 선언적 프로그래밍을 사용하라.
-       자신만의 관성화된 도구 구축에 주의하라 : 프레임워크와 다른 도구에 대한 투자는 흔히 구현의 상세한 부분을 너무 일찍 결정하도록 하는 경우가 많다.
-       반복을 파하라.
-       관심을 분리하라 :  모듈은  정의된  가지 책임만을 맡아야 한다.
-       변화를 캡슐화 하라 : 변화하리라 예측되는 것을 캡슐 안쪽에 두어인터페이스가 안정되게 해야 한다.
-       미래에 필요한 기능은 구현을 미루어라
-       가외 기능을 피하라
n   분야에서 특히 중요한 것이 무엇인지 느끼는 감각을 계발하라.
n  결정을 언제 내려야 하는지 감각을 키워라
n  빨리 반응하는 능력을 키워라
신고

'Programming > Agile' 카테고리의 다른 글

Lean Software Development  (0) 2010.05.25
by Hazard 2010.05.25 14:11

나는 케논이 좋다, 니콘이 좋다, 라이카나 핫셀이 좋다고 떠벌이며 시간을 보내는 사람들을 만나면 조용히 그 자리를 떠난다. 카메라는 ‘해상도’를 표현하기 위한 장비가 아니다. 사진을 찍는 장비다. 해상도가 좋은 사진을 선호하는 사람이 있으면, 일부러 노이즈를 주거나 거칠게 프리트해서 독특한 분위기의 사진을 만들어 내는 작가도 얼마든지 있다. 
  
  내 친구 중에 오디오 시스템을 1억 정도를 들여 듣는 친구가 있다. 진공관 엠프에 스피커도 어마무시하게 크다. 어느 날 그 친구와 음악을 즐기는 사람과 내가 같은 자리에 앉게 되었다. 친구는 자신의 오디오를 자랑했다. 가만히 듣고 있던 다른 친구가 그가 하는 말을 다 듣더니 하는 말이, “선생은 소리를 즐기시는군요. 저는 음악을 즐깁니다.”

  나는 순간 머리가 번쩍 깨는 줄 알았다. 그 사람은 음악 메니어 였고 내 친구는 ‘소리’ 메니어 였던 것이다. 실로 내 친구는 그 비싼 오디오를 가지고 있었지만 거기에 상응하는 소프트웨어가 없었다. 음반이 많이 없었다는 것이다. 그러나 다른 친구는 소담한 장비에 아주 많은 음반을 가지고 있었던 것이다.

  자리가 무색해지고 어색해지자 내가 조용히 말을 듣던 친구에게 물었다.
  “그렇다면 1억이라는 돈을 들여 시스템을 조율하고 엠프를 바꾸고, 스피커로 가는 전선을 다양하게 바꾸는 것은 어떤 의미가 있습니까?”
  그러자 그 친구는,
  “그런 분들 덕분에 오디오 시스템의 질이 조금씩, 아주 조금씩 좋아집니다. 그런 가치가 있습니다.”
  나는 그 말을 듣고 무릎을 치지 않을 수 없었다. 
  해상도나 렌즈의 특성을 따지는 당신 덕분에 좀 더 좋은 장비가 탄생할 수 있을지는 모르나 당신의 사진이 좋아진다는 보장은 없다.

  아, 생각난 김에 한마디만 더 하자.
  “프로는 사진 자랑하고, 아마는 카메라 자랑한다.”는 말이 있다. 
  
  당신은 무엇을 자랑할 것인가?

  세상에서 가장 좋은 카메라는 지금 당신의 수중에 있는 카메라다. 당신과 함께 들로 산으로 돌아다니며 거침없이 일을 해주고 즐거움을 주는 카메라야 말로 세상에서 가장 좋은 카메라라는 것을 지금 이 순간 깨달아야 한다. 
  그래야만 당신은 ‘사진의 본질’에 집중할 수 있다


- 사진가 김홍희
신고
by Hazard 2010.05.19 13:35
웹기반시스템하에서의 성능에 관한 이론적 고찰 
http://www.javaservice.net/~java/bbs/read.cgi?m=qna&b=consult&c=r_p&n=1008701211

먼저, 아파치 access_log 분석을 통해, 사용자에 의한 부하량을 조사하는 것이
우선입니다. access_log 를 이용하시면 다음과 같은 정보를 얻을 수 있습니다.

1) 일중 서로 다른 IP어드레스의 누적치 그래프
   시간당/분당 다녀간 서로 다른 IP어드레스 그래프
   (필요시, Proxy Server 보정치 조정)
2) 일일 동시단말사용자 그래프
3) 동적컨텐츠(Servlet/JSP)에 대한 분당 HIT건수의 일중 그래프

위의 것을 통해, 동시단말사용자에 의한 분당 혹은 초당 요청건수와 그에 따른
한 사용자당 평균 몇 초 간격으로 호출을 하는지를 확인할 수 있습니다.

또한, 과거의 몇 달 동안의 로그가 있다면, 간단히, access_log 의 사이즈
비교만으로도, 사이트의 증가량 및 증가패턴을 이해할 수 있을 것입니다.

4) httpd.conf 파일의 common 로그패턴에 "%T"옵션을 추가하여 해당 요청의
응답시간도 access_log 에 기록토록 하시고 최소한 하루치의 로그를 받으세요.

5) HIT량을 기준으로 한 각 어플리케이션(Servlet/JSP) HIT량 점유 파이 그래프

6) 개별 어플리케이션의 응답시간의 합을 기준으로한 파이그래프

그리고, 이를 통해 가장 응답이 느린 Servlet/JSP와, 또 각 Servlet/JSP별로
그 응답시간의 합을 계산하고 그 비율을 보면, 서버측에서 가장 오랫동안
점유한 서비스의 우선순위를 매길 수 있을 것입니다.

위의 과정을 통해, 어떤 응용어플리케이션이 가장 이 시스템에 어플리케이션적인
부하를 주고 있는지를 리스팅 할 수 있습니다.
경험적으로 볼때, 수백/수천개의 어플리케이션이 있다면 이 중 30-40%만이 사용되며
그 30-40%  중에서도 상위 20%의 어플리케이션이 전체 부하의 80%를 점유하고 있을
것입니다.

7) requestmon 이라는 모듈을 통해, 현재 수행되고 있는 Servlet/JSP 리스트 확인 및
응답이 느린 서비스 추적
관련모듈: 
현재실행중인 서비스 모니터링 - requestmon - 
http://www.javaservice.net/~java/bbs/read.cgi?m=appserver&b=was&c=r_p&n=982131370
Orion 서버에 requestmon 적용하기
http://www.javaservice.net/~java/bbs/read.cgi?m=appserver&b=orion&c=r_p&n=1009556331
Resin2.0.4 서버에 requestmon 적용하기
http://www.javaservice.net/~java/bbs/read.cgi?m=appserver&b=engine&c=r_p&n=1009768606



8) 위의 과정을 통해 상위 몇몇 개의 서비스를 선택하여 웹스트레스 테스트 툴을 이용,
강의시간에도 말씀드렸듯, 단위시간당 최대 처리건수인 TPS를 구하세요. 그리고, 각종
Tuning작업(DB튜닝, SQL튜닝, 파라메터튜닝, OS 튜닝, N/W 용량확인)을 통해
최대TPS를 끌어올리는 작업을 하세요.

9) 그러나, Tuning을 아무리 하여도 한계는 있겠지요... 그 최대 TPS에 따른 실제
발생한 hit량(access_log)을 비교하고, 동시단말사용자 증가에 따른 필요 전체 TPS를
가늠 해 보세요...


10) 특히 일중 동시단말사용자수 변화에 따른 해당 시점의 서비스 상태를 같이
비교하시면,한 머신에서 최대로 처리할 수 있는 동시단말사용자가 몇명 쯤이겠거니를
판단할 수 있을 것입니다. 
이젠 L4/L7나 IBM eND를 통해 여러대의 머신을 클러스트링하여 로드발란싱을 시켜야
할 시점이 되는 것입니다. DB서버의 증설은 당연히 필요할 것으로 보이며,
웹어플리케이션서버(현재는 tomcat으로 운영되고 있군요)의 개수 및 서버용량을
산정해 보세요...

웹기반 시스템하에서의 용량산정은 아직 경험이 없다보니 경험치가 많지 않습니다.
저의 경험치는 다음과 같습니다. 웹어플리케이션서버를 위한 머신의 tpmC 요구량은,

필요서버용량(tpmC) = (동적컨텐츠에의한 분당최대처리건수) x 10tpmC + 여유분50%

입니다. 예를 들어, 초당 100건(100TPS)라면 분당 6,000 TPM 이고, 이는
6,000TPM x 10 tpmC = 60,000 tpmC 이며, 여기에 50%의 Buffer를 첨가하면
90,000 tpmC 가 필요하게 됩니다.

NOTE: 결코 절대적이지 않습니다. 어플리케이션의 특성에 따라 달라지는 것은 당연
하잖습니까. 제가 알기로는, 국내 굴지의 프로젝트에서도 웹서버에 대한 용량산정에
있어서, 만약, 특정한 공식이 있다면, 그 공식은 과거 경험치를 토대로 역산하거나
비즈니스적인 요건에 맞게 미리 서버를 대충 선정하고, 그것에 맞게 그럴싸하게 만든
가라데이타(?, 거짓부렁)입니다. 신뢰하지 마세요 ;-)

작성하신 문구의 어투와, 웹사이트의 구성으로 보건데, 1초당 10건도 처리하지
못하고 있을 듯 합니다. 1초당 10건이라함은(10 TPS), 평균적으로 사용자의
호출패턴이 20초간격으로 한번씩의 호출을 발생시킨다고 가정했을 때,

최대동시단말사용자(x명)/20초 = 10 TPS, 

즉, 최대 동시단말사용자는 200 명이 max가 된다는 얘깁니다.

과거 및 현재 부하량을 분석하고, 어플리케이션의 중요도가 높은 것을 선택하여 
웹스트레스테스트 시행을 통한 개별 최대TPS를 구하고, 향후 증가 예상을 통해
필요한 용량산정을 수치로 제시하여 고객과 협의하세요.

이러한 패턴으로 작업한 각종 문서들이 본 게시판을 찾아 보시면 다수 있습니다.
참고가 될 겁니다.

PS:  첫화면의 모든 데이타 사이즈가 303KB이네요. 임대받은 IDC센타의 N/W 용량은
어떻게 되는지요? 만약 10 Mbps dedicated 라면, 실전송 속도는 대략 이것은 60%로
가정하고, 10 Mbps x 60% x 1024 / 8 = 768 (KB/sec)가 되네요. 만약, 전송해야할
데이타의 평균량이 300KB라고 가정하면,768(kb/sec) / 300(kb) = 2.56 (건/sec)이
됩니다. 즉, 1초당 2.56 개만 서비스할 수 있다는 얘기가 됩니다. 2.56 TPS라는
얘기는 20초마다 한번씩 클릭하는 사용자 51명(2.56 x 20 = 51.2)이 최대 동시단말
사용자수가 될 것입니다.(예를 든 것 뿐입니다. 이미지는 "return code 304" cache가
되니, 얘기가 다르겠지요)

PS: DB Connection Pool을 사용하고 하지 않고는 해당 어플리케이션의 환경과
부하량 규모에 따라 다릅니다. 얼마나 차이나 나느냐 라는 질문은 우문입니다.
경우에 따라 다른 것이지요. 분명한 것은 성능 차이가 있다는 것입니다.

PS: access_log를 DB에 넣고, 이를 분석하는 아기자기한 저만의 프로그램들을
이 곳에 공개합니다. 시간상, 사용법은 향후 다시 문서화 하겠습니다. 엔지니어라면
소스를 보면 뭘 하자는 것인지 이해 하겠지요...

자바서비스넷(http://www.javaservice.net) --> Etc --> 기타자료실

웹로그 분석 프로그램 version 1.0
http://www.javaservice.net/~java/bbs/read.cgi?m=etc&b=etc&c=r_p&n=1015965476


----------------------------------------------------
웹기반 시스템하에서의 용량산정은 아직 경험이 없다보니 경험치가 많지 않습니다.
저의 경험치는 다음과 같습니다. 웹어플리케이션서버를 위한 머신의 tpmC 요구량은,
필요서버용량(tpmC) = (동적컨텐츠에의한 분당최대처리건수) x 10tpmC + 여유분50%
입니다. 예를 들어, 초당 100건(100TPS)라면 분당 6,000 TPM 이고, 이는
6,000TPM x 10 tpmC = 60,000 tpmC 이며, 여기에 50%의 Buffer를 첨가하면
90,000 tpmC 가 필요하게 됩니다.
 

신고
by Hazard 2010.01.14 16:52
| 1 2 3 4 5 ··· 7 |

티스토리 툴바