목차|IV

시작하며 3

성능이란? 501 장

1.1 동시 사용자 6

1.2 처리량 7

1.3 응답시간 8

1.4 자원 12

1.4.1 적정성 12

1.4.2 효율성 13

1.4.3 안정성 13

1.4.4 가용성 13

1.4.5 확장성 14

성능특성 1502 장

2.1 성능 곡선 15

2.2 성능에 대한 이해 16

성능이론 1903 장

3.1 기초 성능 이론 19

3.2 사용률 이론 22

3.3 비율 분석 23

성능테스트 2504 장

4.1 성능 테스트 유형 25

4.2 성능 테스트 구성 요소 27

성능기초

01부

목차 | V

4.3 성능 테스트 시 주의사항 28

4.3.1 테스트 데이터 28

4.3.2 화면 처리시간 30

4.3.3 네트워크 30

4.3.4 가상 사용자 특성 31

4.3.5 업무 시나리오 32

4.3.6 대상 업무와 성능 개선 33

기본자세 3501 장

성능분석시작하기 3702 장

2.1 애플리케이션 서버 응답시간 분석 38

2.2 클라이언트 응답시간 분석 39

상황별분석단계 4103 장

3.1 화면 응답시간 저하 41

3.2 시스템 내 응답시간 저하 44

3.3 서비스 멈춤 현상 47

3.4 시스템 전반에 걸친 성능 개선 49

3.5 서버 자원 사용량 확인 50

3.6 CPU 과다 사용 분석 51

3.7 메모리 과다 사용 분석 53

3.8 디스크 과다 사용 분석 57

개선방향성 6104 장

성능개선

02부

목차|VI

기본방향 6501 장

HTTP의이해 6702 장

2.1 프로토콜 구조 67

2.2 HTTP 요청 68

2.3 HTTP 응답 72

2.4 데이터 송수신 78

화면응답시간모니터링 8003 장

3.1 화면 응답시간 모니터링 도구 80

3.2 인터넷 익스플로러 프로파일링 83

3.3 피들러 86

3.4 HTTP 분석 접근 91

웹기반시스템성능개선 9204 장

4.1 화면 콘텐츠 구성 92

4.1.1 콘텐츠 수 축소 92

4.1.2 크기별 이미지 준비 96

4.1.3 이미지 콘텐츠 파일의 크기 축소 97

4.1.4 CDN 사용 98

4.1.5 텍스트 콘텐츠의 크기 축소 99

4.1.6 압축 적용 100

4.1.7 웹 가속기 106

4.2 캐시 동작 107

4.2.1 브라우저 캐시 107

화면응답시간분석

03부

목차 | VII

4.3 병렬/비동기 처리 118

4.3.1 네트워크 연결 증가 118

4.3.2 AJAX와 DOM을 이용한 비동기 처리 119

4.4 기타 성능 개선 120

4.5 웹 서버 설정 121

4.5.1 최대 병렬 처리 수 121

4.5.2 Keepalive 122

웹서버모니터링 12705 장

5.1 웹 요청 응답시간 모니터링 127

5.2 웹 서버 성능 모니터링 129

HTTPS 13606 장

기본방향 14101 장

수행중인코드 14302 장

2.1 스택에 대한 이해 143

2.2 스택 정보를 이용한 성능 분석 146

2.2.1 스택 대기 분석 147

2.2.2 교착상태 157

2.2.3 스택 성능 분석 161

2.3 스택 수집 164

2.4 프로세스 스택 분석 도구 171

2.4.1 환경설정 173

2.4.2 주요 기능 설명 191

2.4.3 SDPA를 이용한 성능 분석 195

프로세스이해하기

04부

목차|VIII

통신/파일상태 19803 장

3.1 파일 지시자의 이해 198

3.2 연계 통신/파일 상태 정보를 수집하는 방법 201

통신/파일간동작 20704 장

4.1 시스템 콜에 대한 이해 207

4.2 통신/파일 상태와 동작 연계 분석 210

4.3 스택 정보와 통신/파일 간 동작 연계 분석 212

4.4 통신/파일 간 동작 모니터링 방법 213

기타 21905 장

5.1 프로그램 소스코드 보기 219

5.2 바이너리 코어 덤프에서 자바 스택이나 힙 정보를

추출하는 방법 220

5.3 프로세스의 현재 작업 디렉터리를 확인하는 법 222

5.4 프로그램에서 사용하는 공유 라이브러리 확인 222

5.5 프로세스 생성 관계 보기 223

5.6 프로세스의 수행 환경 확인 224

기본방향 22701 장

불필요한작업제거 23002 장

2.1 로깅 230

2.1.1 잘못 사용된 로깅 수준 230

2.1.2 로깅을 위한 불필요한 메시지 생성 231

소스코드최적화

05부

목차 | IX

2.1.3 로깅을 효율적으로 하기 위한 개선 233

2.1.4 트랜잭션 저널 로그 234

2.2 불필요한 로직 236

2.3 반복 로직 237

로직최적화 24103 장

3.1 락 최소화 241

3.1.1 락 범위 최소화 241

3.1.2 락 제거 243

3.2 문자열 처리 개선 247

3.2.1 String.format 메서드 247

3.2.2 String.replaceAll 메서드 248

3.2.3 문자열 합치기 249

3.3 리플렉션 호출 제거 250

3.4 채번 251

3.5 날짜 연산 256

3.6 시간 문자열 처리 263

3.7 순차 검색 제거 266

3.8 파일 입출력 단위 268

3.9 SQL 270

3.10 BigDecimal 275

3.11 비대기 입출력 사용 278

3.12 기타 성능 개선 279

3.13 코드 성능 측정 281

적극적인캐시사용 28404 장

목차|X

효율적인아키텍처구성 28705 장

5.1 병렬 처리 287

5.2 통신전문 291

5.3 고객정보 조회 이력 로깅과 마스킹 293

5.4 대량 조회 프레임워크 구성 294

5.5 내부 연계시스템 295

5.6 수직확장과 수평확장 296

기본방향 30101 장

SQL튜닝을위한지본지식 30302 장

2.1 데이터베이스의 기본 구조 303

2.2 블록 단위 처리 306

2.3 캐시 IO 대 물리 IO 309

성능개선대상식별 31003 장

3.1 SQL 수행 통계 310

3.2 실행 중인 세션 상태 312

3.3 수행 중인 SQL의 수행 상태 확인 314

3.4 락 대기 317

3.5 AWR 보고서 319

3.6 StatsPack 328

SQL튜닝

06부

목차 | XI

SQL실행계획 33604 장

4.1 SQL 실행계획과 수행 결과 336

4.1.1 SQL 실행계획 보기 336

4.1.2 SQL 수행 결과 확인 338

4.2 실행계획의 이해 342

4.2.1 조인 344

4.2.2 SQL 실행계획의 동작 355

4.3 인덱스 360

4.3.1 인덱스 구조 361

4.3.2 인덱스 종류 362

4.3.3 인덱스 사용 원칙 365

4.3.4 인덱스 탐색 방식 366

4.3.5 인덱스 수와 성능 370

4.4 테이블 371

4.4.1 Direct-Path와 Conventional-Path 371

4.4.2 파티션 테이블 372

4.5 테이블 통계 보기 374

SQL성능개선 38005 장

5.1 힌트 사용 380

5.2 SQL 성능 개선 389

5.2.1 인덱스 부재 389

5.2.2 인덱스 항목 순서 390

5.2.3 LIKE에 의한 성능 저하 392

5.3.4 테이블 조인 이상 392

5.3.5 실행 횟수와 조인 393

목차|XII

기본방향 39901 장

중복SQL수행제거 40102 장

2.1 애플리케이션 캐시의 종류 402

2.1.1 블록 캐시 402

2.1.2 요청 캐시 403

2.1.3 사용자 세션 캐시 404

2.1.4 프로세스 캐시 404

2.1.5 프로세스간 공유 캐시 405

2.1.6 캐시 특성 분류 406

2.2 요청 캐시 구현 코드 407

2.3 캐시 적용 411

불필요한SQL수행제거 41403 장

최적수행 41904 장

4.1 Rownum 추가 419

4.2 파티션 키 추가 425

4.3 조회 항목 사용 여부(테이블 조인 제거) 430

쿼리통합 43105 장

5.1 메인/서브 쿼리 431

5.2 병렬 쿼리 통합 432

애플리케이션입장에서의SQL튜닝

07부

목차 | XIII

DB집합처리 43306 장

트랜잭션처리 43507 장

기타 43708 장

8.1 복합적인 기능을 수행하는 쿼리 제거 437

8.2 스칼라 서브 쿼리 사용 시 주의사항 441

8.3 페이징 처리 443

배치성능개선 44709 장

9.1 전체 테이블 탐색 448

9.2 파티션 453

9.3 해시 조인 454

9.4 병렬 처리 457

9.5 쿼리 통합 459

9.5.1 메인리더와 건별 처리 쿼리 통합 459

9.5.2 메인리더와 Insert 통합 462

9.5.3 Select / Insert / Update 통합 463

9.6 자바 배치 모니터링 방안 464

APM활용 47110 장

10.1 스카우터 473

목차|XIV

기본방향 48301 장

CPU 48602 장

2.1 사용량 분석 486

2.2 CPU 확인 488

2.3 동시 다중 스레딩 489

2.4 CPU를 많이 사용하는 스레드 식별하기 491

2.5 프로세스의 누적 CPU 사용량 확인하기 492

2.6 CPU를 많이 사용하는 모듈(코드) 식별하기 494

메모리 50903 장

3.1 가상 메모리 510

3.2 메모리 관련 주요 용어 511

3.3 사용량 분석 513

3.4 메모리 확인 520

디스크 52104 장

4.1 사용량 분석 521

4.2 유닉스/리눅스 디스크 관리 532

4.3 파일시스템의 입출력 방식 537

4.3.1 비동기 입출력 537

4.3.2 직접 입출력 538

4.3.3 동시 입출력 539

4.4 스토리지 543

서버OS모니터링

08부

목차 | XV

4.5 레이드 545

4.5.1 레이드 0 – 스트라이핑 545

4.5.2 레이드 1 – 미러링 546

4.5.3 레이드 0+1 - 스트라이핑과 미러링 546

4.5.4 레이드 4 – 스트라이핑과 전용 패리티 547

4.5.5 레이드 5 – 스트라이핑과 분산 패리티 547

통합모니터링도구 54805 장

5.1 nmon 548

5.2 topas 552

5.3 GlancePlus 553

5.4 top 559

기본방향 56301 장

바이너리메모리관리 56402 장

2.1 프로세스 메모리 구조 564

2.2 메모리 누수 조사 570

2.2.1 윈도우 571

2.2.2 AIX 576

2.2.3 솔라리스 578

2.2.4 HPUX 585

2.2.5 리눅스 589

2.2.6 기타 592

프로세스의메모리구조

09부

목차|XVI

자바메모리관리 59303 장

3.1 JVM 메모리 구조 593

3.2 가비지 컬렉션 594

3.3 오라클/HP JVM의 힙 메모리 구조 595

3.4 오라클/HP JVM의 GC 방식 598

3.4.1 Serial GC 598

3.4.2 Incremental GC 598

3.4.3 Parallel GC 599

3.4.4 Parallel Old GC 599

3.4.5 Concurrent Mark and Sweep(CMS) GC GC 600

3.4.6 Garbage First(G1) GC 602

3.4.7 GC 선정 기준 605

3.5 IBM JVM의 메모리 구조 609

3.5.1 단일 공간 메모리 구조 610

3.5.2 Generation space 메모리 구조 613

3.6 IBM JVM의 GC 방식 614

3.7 자바 힙 메모리 누수 615

3.8 자바 힙 메모리 모니터링 623

3.8.1 jstat 624

3.8.2 모니터링 콘솔 626

3.8.3 GC 로깅 629

3.9 자바 힙 덤프 수집 637

3.9.1 jmap 638

3.9.2 이벤트 설정 639

3.9.3 HPROF 640

3.10 메모리 분석(이클립스 MAT 1.2.1 버전) 644

3.10.1 시작하기 646

3.10.2 화면 구성 647

3.10.3 주요 용어 설명 648

3.10.4 주요 메뉴 655

목차 | XVII

기본방향 66501 장

네트워크기초 66702 장

2.1 OSI 7 계층 668

2.2 TCP/IP와 UDP/IP 670

2.3 스위치 671

2.4 운영체제별 네트워크 설정 확인 672

IP 67403 장

3.1 기본 개념 674

3.1.1 IP 주소 674

3.1.2 IP 주소의 클래스 676

3.1.3 IP 주소의 사이더 677

3.1.4 서브넷 마스크 678

3.1.5 게이트웨이 679

3.1.6 점보 프레임 680

3.2 IPv6 681

3.3 IP 프로토콜 네트워크 체크 명령 681

3.3.1 호스트 IP 설정 확인 681

3.3.2 Ping 명령 683

3.3.3 호스트의 라우팅 테이블 확인 686

3.3.4 Trace route 명령 687

3.3.5 nbtstat 명령 689

네트워크모니터링

10부

목차|XVIII

TCP 69004 장

4.1 기본 개념 690

4.2 TCP 전송 보장 698

4.2.1 전송 보장 알고리즘 698

4.2.2 선별적인 ACK 705

4.3 전송 제어 706

4.3.1 수신 윈도우 707

4.3.2 송신 윈도우 708

4.3.3 슬라이딩 윈도우 711

4.4 네이글 알고리즘 712

4.5 TCP KeepAlive 716

4.6 TCP 프로토콜 네트워크 체크 717

4.6.1 telnet [IP address] [port] 명령 717

4.6.2 netstat –an 명령 719

4.6.3 netstat –s –p [protocol] 명령 720

UDP 72505 장

기타프로토콜 72706 장

6.1 DNS 727

6.2 FTP 730

목차 | XIX

네트워크데이터수집방법 73207 장

7.1 유닉스/리눅스 공통 733

7.2 HP-UX 736

7.3 IBM AIX 737

7.4 오라클 솔라리스 738

7.5 윈도우 739

네트워크패킷분석(와이어샤크1.10.6버전) 741

08 장

8.1 화면 구성 741

8.1.1 패킷 목록 743

8.1.2 패킷 프로토콜 정보 743

8.2 필터링 744

8.3 기초 분석 메뉴 748

8.5 응답시간 분석 751

8.5.1 네트워크 시간 752

8.5.2 서버 시간 754

8.5.3 클라이언트 시간 755

8.6 전문 분석 756

8.7 재전송 분석 757

8.8 와이어샤크를 이용한 성능 분석 760

시스템 성능 개선과 문제해결 분야에서 15년간 활동하면서 쌓인 경험을 정리해 후배와 성능 관련

업무를 시작하는 분들에게 도움이 되고자 이 책을 씁니다.

성능 개선과 관련해서 데이터베이스 SQL 튜닝을 다룬 책은 시중에 많이 있고, 데이터베이스 최적화

전문가 시장도 상당히 큽니다. 하지만 실제 업무 로직이 수행되는 애플리케이션 코드 측면에서 성능

을 분석하고, 데이터베이스에 접근하는 책은 거의 없을 뿐 아니라 시장에서 애플리케이션 최적화 인

력은 찾기도 어려운 실정입니다. 애플리케이션 최적화 전문가는 서버와 데이터베이스부터 업무 로

직까지 복합적인 지식이 필요하기 때문에 진정한 시스템 최적화 전문가라고 할 수 있습니다.

이 책에서는 단순한 성능 개선 프로세스와 원칙에 대한 원론적인 설명은 최소화하고, 기술적인 내용

을 중심으로 업무에 도움될 수 있는 실질적인 성능 분석과 개선 사례 위주로 내용을 담았습니다. 시

스템 성능은 서버, 애플리케이션, 데이터베이스, 네트워크에 관한 개별 지식만으로는 분석하는 데

한계가 있습니다.

성능 개선을 위해서는 각 기술 요소의 특성과 동작 방식을 전체 시스템 관점에서 이해하고 분석할

수 있는 능력이 필요하므로 새로운 신기술보다는 프로그램 동작을 정확히 분석할 수 있는 기초 지식

에 대한 이해도가 높아야 합니다. 그래서 이 책에서는 애플리케이션과 다소 연관성이 떨어져 보이

는 운영체제, 네트워크 같은 부분에 대한 기초 지식을 다룸으로써 독자의 시스템 이해도를 높이려고

노력했습니다. 기술 영역은 기반 기술이라 할 수 있는 HTTP, 자바, 오라클 데이터베이스, 유닉스,

TCP/IP를 중심으로 기술했습니다.

시작하며

3시작하며

성능을 개선할 때는 서비스를 처리하는 각 구성 요소의 처리시간을 세분화해서 성능 분석을 해야

합니다. 그러나 처음 접하거나 구성이 복잡한 시스템을 효과적으로 세분화해서 측정한다는 것은 쉬

운 과정이 아닙니다. 그래서 효율적으로 시스템의 동작 방식과 구성을 이해하고 분석할 수 있게 지

원하는 적절한 모니터링 도구의 선정이 무엇보다 중요합니다.

그러나 인터넷을 검색해 보면 수많은 성능 개선과 문제해결 사례가 있고, 업무에 참조할 수 있는 모

니터링 도구도 많지만 이것들을 체계적으로 정리한 사이트나 책이 없는 것이 현실입니다. 그래서 모

니터링 도구를 단순히 나열하는 것으로도 보일 수 있지만 시스템의 각 부분에 적용 가능한 모니터링

도구를 최대한 많이 다루고, 실제로 사용하는 모습을 담아 독자의 이해를 조금이나마 높이고자 했습

니다.

성능 개선은 대상 시스템이 어떤 기능을 수행하는 데 시간과 자원을 많이 사용하는지 파악하는 것에

서 출발합니다. 이 연장선 상에서 성능을 이해하는 데 각 도구를 어떤 용도로 활용할 수 있는지 생각

하면서 이 책을 읽으면 도움될 것입니다.

마지막으로 집필이라는 새로운 일을 할 수 있게 힘이 되어준 사랑하는 아내 경선과 두 아들 지용, 지

훈, 그리고 책 출판을 처음 제안해 준 동기 김창선에게 고마움을 전합니다.

* 책에서 소개된 주요 소스는 http://blog.daum.net/mskweon82 에서 내려받을 수 있습니다.

일반인에게 물을 보내는 파이프의 성능이 무엇인지 물어본다면 “시간당 보내는 물의 양”이라고 대

부분 답할 것이다. 그리고 파이프의 성능에 영향을 미치는 요소는 물이 흐르는 속도와 파이프의 직

경이라고 대답할 것이다.

이는 대부분의 사람들이 성능의 의미를 이미 알고 있다는 뜻이다. 파이프의 직경이 동일한 경우

10M/sec 속도로 보내는 파이프가 5M/sec로 보내는 파이프에 비해 시간당 보내는 물의 양이 2배

많으므로 성능 측면에서도 2배라고 말할 수 있다.

시스템 성능도 파이프의 성능과 동일하다. 시스템 성능은 시간당 처리량이며, 영향을 미치는 요소는

응답시간과 동시에 처리할 수 있는 프로세스 수다.

직경

속도 응답시간

파이프시스템

프로세스 수

[그림 1-1] 성능에 영향을 미치는 요소

파이프에 끈적끈적한 기름을 보내는 경우에는 기름의 성질 때문에 흘러가는 속도가 느려져 물을 보

내는 경우에 비해 같은 시간 동안 보낼 수 있는 양이 줄어든다. 이것은 동일한 파이프라고 하더라도

성능이란?

01장

1부 _ 성능 기초6

어떤 내용물을 보내느냐에 따라 성능이 달라진다는 것을 의미한다. 시스템도 마찬가지다. 고객의 업

무 특성과 아키텍처에 따라 응답시간에 차이가 나타나고 성능도 달라진다.

응답시간은 사용자의 특성과 환경에 따라 요구하는 수준이 다르므로 동일한 응답시간에 대해 고객

마다 만족도는 다르게 나타난다. 이는 모든 시스템과 사용자에게 일률적으로 적용할 수 있는 응답시

간의 기준은 없다는 것을 의미한다.

앞에서 설명한 내용을 종합하면 성능을 다음과 같이 정의할 수 있다.

“고객의 특정 업무를 대상으로 운영환경하에서 고객이 수긍할 수 있는 응답시간 내에 처리할 수 있

는 거래량”

이어서 성능을 평가할 때 일반적으로 사용하는 용어를 설명하겠다.

1.1동시사용자

성능 테스트나 운영 시 시스템에 발생하는 부하(Load)의 의미로 많이 사용되는 용어가 바로 동시

사용자(Concurrent User)다. 하지만 동시 사용자에 대한 정의를 개발자와 업무담당자 간에도 다르

게 해석하는 경우가 많다. 일반적으로 “시스템과 접속을 유지하고 있는 사용자 수”로 해석되지만 일

부는 “동시(일정 시점)에 시스템에 트랜잭션을 유발시키는 사용자”로 해석하기도 한다. 고객이 의미

하는 동시 사용자가 동시 부하를 발생시키는 후자의 의미였는데, 접속 사용자로 해석했다면 측정 값

은 신뢰를 완전히 잃어버리고 만다.

성능 분석이나 테스트 시 공식적으로 적용되는 동시 사용자라는 의미는 대상 서버에 접속하고 있는

사용자로 정의한다. 현재 일반화돼 있는 웹 기반 시스템의 경우 비연결 상태로 서버와 접속 및 인증

상태가 유지되는데, 이 경우에도 사용자가 화면을 보고 있거나 입력하고 있다면 동시 사용자에 포함

된다.

동시 사용자는 아래와 같이 다시 두 유형으로 나뉘며, “동시 사용자 수 = 요청 사용자 수 + 비요청

사용자 수”라는 공식이 성립한다.

1. 요청 사용자(Active user): 대상 서버에 부하를 발생시키고 있는 사용자로서 서버에 서비스를 요청한 후 응답을 기

다리고 있는 사용자

2. 비요청 사용자(Inactive user): 대상 서버에 접속해 화면 내용을 읽고 있거나 화면에 값을 입력하는 중이라서 현재

서버에 서비스 요청을 보내고 있지 않는 사용자

71장. 성능이란?

1.2처리량

처리량(throughput)은 서버가 일정 시간 내에 처리한 트랜잭션(transaction)의 양이다. 그런데 서

버가 인식하는 트랜잭션과 사용자가 인식하는 트랜잭션은 다르다. 예를 들어, 어떤 웹 기반 고객정

보 조회 화면이 12개의 이미지, CSS(Cascading Style Sheets), JS(JavaScript)와 메인 JSP(Java

Server Pages), 그리고 5개의 AJAX(Asynchronous JavaScript and XML) 호출로 이뤄져 있고,

JSP와 AJAX 호출 중 3개에 DB 호출이 있고 100개의 쿼리가 수행된다고 가정해 보자. 아래와 같이

각 서버 입장에서 트랜잭션을 보면 서버의 역할과 화면을 구성하는 방식에 따라 트랜잭션 수가 달라

진다.

[표 1-1] 서버별 트랜잭션 수

서버 구분 트랜잭션 수 트랜잭션 구성

웹 18 이미지/CSS/JS 12개 + JSP 1개 + AJAX 5개

애플리케이션 6 JSP 1개 + AJAX 5개

DB 100 JSP/AJAX 3개에서 100개 쿼리 수행(DB 트랜잭션 처리 3개)

하지만 해당 서비스를 요청하는 고객 입장에서는 고객 조회라는 1개의 트랜잭션을 보냈을 뿐이으로

서버 입장에서의 트랜잭션과는 다르다.

성능에서 중요한 것은 DB가 데이터를 몇 건 처리하고, 웹 서버가 이미지나 CSS 콘텐츠를 몇 건 처

리했는가가 아니라 고객의 업무를 얼마나 빨리 처리할 수 있는가다. 따라서 처리량의 평가 단위로서

TPS(Transaction Per Second)의 “T”는 고객의 업무 처리 건수가 되는 것이 고객과의 의사소통

을 위해서나 업무 시스템을 평가하는 데 적합하다.

그러나 시스템을 설계하고 분석하는 엔지니어 입장에서는 서버가 인식하는 트랜잭션 또한 시스템을

이해하고 개선 방향을 수립하는 데 중요한 의미를 지닌다. TPS 이외의 처리량 평가 단위로 PPS와

HPS가 있다.

1. PPS(Page Per Second)

웹 성능을 분석할 때는 화면 단위(Page)를 트랜잭션 평가 단위로 사용하기도 한다.

“사용자 등록 화면 → (ID 입력) → ID 중복 확인 화면 → 주소 검색 초기 화면 → 주소 검색 결과 화면 → (기타 정보

입력) → 사용자 등록 성공 화면” 단계로 사용자 등록 흐름이 구성돼 있다면 PPS 관점에서의 처리량은 화면이 전환

되는 기준으로 5가 된다.

그러나 업무를 기준으로 한 TPS 관점에서의 처리량은 사용자 등록이라는 하나의 업무이므로 1이 된다.

1부 _ 성능 기초8

2. HPS(Hit Per Second)

웹 서버에서 이미지, 스크립트 파일, 스타일 파일, JSP, ASP 등 모든 컴포넌트는 별개의 요청으로 구성되며, 각각이

1개의 Hit가 된다. 따라서 HPS를 측정 단위로 삼는다면 TPS나 PPS에 비해 세분화된 것으로 볼 수 있다.

그동안의 경험을 비춰볼 때 대부분의 시스템은 최대 500TPS 이내인 것이 일반적이다. 은행의 뱅킹

시스템이나 통신사의 고객정보시스템과 과금시스템 같은 시스템 정도가 돼야 1,000TPS가 넘는다.

1.3응답시간

응답시간은 요청(Request)한 후부터 응답(Response)을 받을 때까지 소요된 시간으로, 측정하는

위치에 따라 여러 유형으로 나뉜다.

1. 클라이언트 응답시간

사용자가 요청한 후부터 화면에 응답이 나타날 때까지 경과된 시간을 의미한다. 따라서 클라이언트 내부 처리시간

도 포함된다.

그리고 화면이 보이기 시작할 때를 기준으로 할지, 화면이 완성됐을 때를 기준으로 할지에 따라 응답시간이 달라진

다. 성능 개선에서는 사용자가 느끼는 감성 측면의 응답시간도 중요한 요소로서 진행상태 표시 등 화면을 구성하는

방식과 응답이 보이기 시작하는 시점 같은 것도 개선의 대상이 된다.

클라이언트 응답시간을 세분화하면 클라이언트 내부 처리시간과 네트워크 응답시간으로 나눌 수 있으며, 내부 처리

시간은 다시 화면 렌더링 시간과 클라이언트 로직 처리시간으로 나뉜다.

2. 네트워크 응답시간

사용자 요청이 클라이언트(PC) 네트워크에서 전송된 후부터 응답이 클라이언트 네트워크에 도착하는 데까지 경

과된 시간을 의미한다. 대표적인 성능 테스트 도구인 HP사의 로드러너(LoadRunner)1는 웹 테스트를 수행할 때

HTTP/HTTPS 프로토콜을 기반으로, TP Monitor 테스트 시에는 TP API Call 기반으로 응답시간 측정이 이뤄지므

로 클라이언트 로직 처리와 화면 렌더링 시간은 제외돼 있다. 따라서 HTTP나 TP Monitor 테스트 시에 측정된 로드

런너 응답시간은 네트워크 응답시간이다.

네트워크 시간을 세분화하면 DNS 룩업 시간과 서비스 업로드/다운로드에 소요된 네트워크 시간, 그리고 서버 응답

시간으로 구분된다.

3. 서버 응답시간

서버가 사용자 요청을 받은 후부터 처리 결과를 내보내는 데까지 경과된 응답시간이다. 웹 액세스로그나 애플리케

이션 서버 로그 혹은 APM(Application Performance Management) 기반으로 측정하는 경우가 여기에 해당한다.

서버 응답시간을 세분화하면 웹 서버, 애플리케이션 서버, 데이터베이스 서버 내의 각 처리시간과 대내외 타 시스템

연계 응답시간으로 나뉜다.

1 http://www8.hp.com/kr/ko/software-solutions/loadrunner-load-testing/

91장. 성능이란?

4. 연계 응답시간

서버 처리 중 대외 기관이나 내부 타 시스템과 연계해서 처리할 경우 대내외 연계 서버에 요청을 보내 응답을 받기

까지 경과된 시간이다.

대외 기관과 연계된 서비스의 경우 전체 응답시간에서 대외기관의 응답시간을 구분해서 관리하는 것은 성능 분석

및 개선 시 접근 방향을 설정하기 위한 중요한 기초 데이터가 된다.

대내외 연계 응답시간은 연계 서버(FEP, ESB) 내 처리시간과 연계 서버를 기준으로 한 타 시스템과의 네트워크 응

답시간과 서버 응답시간으로 구분할 수 있다.

네트워크 응답시간

클라이언트 응답시간

서버 응답시간

연계 응답시간

클라이언트 처리시간

렌더링 화면 로직

DNS

웹

업로드

애플리케이션 데이터베이스 연계 서버 타 시스템

다운로드 서버 처리시간

네트워크 처리시간

[그림 1-2] 응답시간 구분

당연히 측정하는 위치가 서버에 가까워질수록 응답시간은 줄어들어 실 사용자가 체감하는 응답시간

과 차이가 발생한다. 따라서 정확한 성능 분석을 위해서는 실 사용자가 위치한 곳에서 클라이언트

응답시간을 측정하는 것이 가장 정확하다.

단순평가를 위한 측정이라면 응답시간만 측정해도 무방하지만 성능 개선을 목적으로 한다면 전체

응답시간 이외에 내부 각 구성 요소에 대해 세분화된 처리시간을 수집하고 분석해야 성능 개선을 어

느 부분에 집중할지 대상을 설정할 수 있다. 따라서 성능 개선 작업을 예정하고 있다면 처리시간을

세분화해서 측정할 수 있는 방안을 수립하는 것이 선행돼야 한다.

성능 개선에서는 “아는 만큼 보인다”라는 진리가 “보이는 만큼 개선할 수 있다”로 연결된다. 클라이

언트, 웹 서버, 애플리케이션 서버, 데이터베이스 서버, 연계 서버 등 많은 서버에 대해 모두 측정할

수 있는 방안을 마련해야 할까? 그렇지는 않다.

사용자가 응답시간이 느리다고 하면 클라이언트 응답시간을 기준으로 분석을 시작할 것이다. 클라

이언트 응답시간 분석을 통해 오래 걸리는 부분이 클라이언트 내부인지, 네트워크인지, 화면 콘텐츠

나 서비스 요청 구성 때문인지, 서버 내부인지 구분할 수 있다.

1부 _ 성능 기초10

서버의 성능이 나쁘다면 애플리케이션 서버를 중심으로 성능을 분석한다. 애플리케이션 서버는 가

장 중요한 핵심 업무 로직이 존재하고, 애플리케이션 서버를 기준으로 웹 서버를 포함한 앞단 처리

시간, 데이터베이스 처리시간, 애플리케이션 내부 처리시간, 연계 서버 처리시간 등을 구분해서 측

정할 수 있어 서버 한 곳에서 측정하지만 가장 세분화된 처리시간을 얻을 수 있는 곳이다. 그래서 성

능을 분석할 때 애플리케이션 서버에서 모니터링하는 제니퍼 같은 APM이 핵심적인 역할을 하는 것

이다.

그러나 성능 개선 전문가라면 모든 시스템에 APM과 같은 모니터링 도구가 설치돼 있는 것은 아니

므로 애플리케이션 서버나 연계 서버에 대해 세부 응답시간을 분석할 수 있는 능력을 갖춰야 한다.

필요에 따라서는 APM에서 보여주는 측정 데이터 이상으로 더욱 세분화해서 분석해야 하는 경우도

많다.

성능을 평가할 때 사용하는 응답시간이라고 하면 많은 사람들은 평균 응답시간을 생각할 것이다. 아

래의 평균 응답시간이 동일한 그래프 세 개를 보자.

응

답

시

간

응

답

시

간

응

답

시

간

시간 시간 시간

[그림 1-3] 응답시간 그래프

첫 번째 그래프는 시간이 지날수록 계속 응답시간이 증가하는 패턴을 보이고 있어 측정시간이 더

길어지면 응답시간이 계속 증가할 것이라는 추측이 가능하므로 시스템에 뭔가 이상이 있다고 볼

수 있다.

두 번째 그래프는 응답시간이 아주 불규칙하다. 사용자가 시스템을 사용할 때 정확한 응답시간을 예

상하는 것 자체가 어렵다. 세 번째 그래프는 가장 안정적인 응답시간 패턴을 보여주므로 사용자는

항상 일정한 응답시간을 경험할 것이라고 예상할 수 있다. 하지만 평균으로 바라본 세 가지 그래프

의 응답시간 수준은 동일하므로 품질이 동일해 보인다. 이러한 오류를 범하지 않기 위해서는 성능

평가 시 전체 사용자 중 일정 비율은 제시된 시간 내에 응답을 받을 것이라는 보장의 의미를 가지고

있는 백분율 응답시간을 사용한다.

111장. 성능이란?

백분율 응답시간은 측정시간 동안 발생한 모든 트랜잭션을 응답시간이 빠른 것부터 일렬로 줄을 세

워 트랜잭션 전체 수 대비 해당 %(th)에 위치한 응답시간을 의미한다.

응답시간

트랜잭션

100%90%80%70%50%

Max

Min

[그림 1-4] 백분율 응답시간 그래프

측정시간 동안 200개의 트랜잭션이 발생했고, 가장 응답시간이 빠른 것부터 줄을 세워 180등을 기

록한 트랜잭션의 응답시간을 봤더니 3.5초였다고 한다면 해당 업무의 90% 응답시간은 3.5초가 되

는 것이다.

90th 응답시간 3.5초 = 200 * 0.9(90%)등을 기록한 트랜잭션의 응답시간

170등을 기록한 트랜잭션의 응답시간이 3초라면 85% 응답시간이 되는 것이다.

85th 응답시간 3.0초 = 200 * 0.85(85%)등을 기록한 트랜잭션의 응답시간

90th 응답시간이 3.5초라면 해당 업무를 사용하는 전체 사용자의 90%는 3.5초 이내의 응답시간을

경험하리라고 보장하는 의미를 가지고 있어 성능 평가에 효과적이다. 그런데 혹시 이런 생각을 하는

독자도 있을 것이다.

“그럼 100% 응답시간을 사용하면 전체 거래에 대한 응답시간이 보장되어 좋겠네”

시스템을 개발해서 운영해 보신 분이라면 운영 환경에서도 예상치 못한 응답시간을 보이는 경우가

종종 있다. 사용자가 입력한 데이터의 특성, 시스템 내부 자원의 순간적인 부족 등의 이유로 항상 1

초 이내에 처리되던 업무가 5초에서 10초 이상 걸리는 경우도 발생한다.

1부 _ 성능 기초12

이러한 예외적인 상황이 발생했을 때 응답시간을 성능 평가에서 제외하는 목적으로도 백분율 응

답시간을 사용한다. 따라서 통상적인 업무 시스템에서는 100% 응답시간을 사용하는 경우가 없고

90% 응답시간을 사용하는 것이 일반적이다. 다만 핵심 기간계 시스템에서는 95% 응답시간을 사용

하는 경우도 있다.

평균 응답시간을 성능 평가 기준으로 정했다면 평균 응답시간 외에 표준편차와 최솟값, 최댓값도 함

께 표기해야 성능을 판단할 수 있다. 평균 응답시간이 동일하더라도 표준편차가 작은 것이 안정적인

응답시간을 제공한다는 것을 의미하고, 최솟값과 최댓값의 차이가 너무 크다면 측정 시 시스템에 이

상이 있거나 예상치 못한 대량의 데이터 처리가 있었다는 것을 의미한다. 성능에서 평균 응답시간이

의미를 가지려면 일반적으로 표준편차가 평균 응답시간의 1/3 이하여야 한다.

1.4자원

성능에서 자원(Resource)은 다양한 시스템 구성 요소를 지칭하는 포괄적인 용어다. 서버의 CPU,

메모리, 디스크, 네트워크 자원부터 WAS(Web Application Server)의 스레드 풀, DB 연결 풀, 힙

메모리, 그리고 DB의 최대 프로세스 수, 오픈 가능한 커서 수, 공유 캐시 메모리 크기 등 물리적인

자원부터 시스템 소프트웨어의 설정값에 이르기까지 다양한 자원이 있다.

그럼 성능 측면에서 자원은 어떻게 정의할 수 있을까? 성능 측면에서 자원은 한정된 값을 가진 시스

템 구성 요소 중 애플리케이션이 동작할 때 사용하며, 부족한 경우나 사용량 변화에 따라 성능에 영

향을 미치는 요소를 의미한다. 자원은 목표 성능을 달성할 수 있게 하는 중요 기반요소로서, 성능 평

가나 분석 시 자원 사용량도 모니터링해서 다음과 같은 관점에서 평가한다.

1.4.1적정성

적정성(Suitability)은 핵심 항목으로, 자원 사용량에 대한 목표 달성과 부족 여부를 확인하는 것이

다. 자원이 부족한 경우 경합과 대기가 발생해 성능이 저하되므로 늘려줘야 하지만 다른 자원에 악

영향을 주어 개선 효과를 보지 못할 수도 있고, 다른 자원 부족의 여파로 영향을 받은 부수적인 부족

문제일 수도 있으므로 세심한 판단과 대응이 필요하다.

예를 들어, WAS 스레드 풀(Thread pool)에 있는 모든 스레드들이 작업 중이라서 새로 요청하는

서비스가 큐잉되고 있다고 하자. 이때 스레드 풀 설정이 부족하다고 판단해 일방적으로 늘려서는 안

된다. 당시 CPU나 자바 힙 메모리와 같은 인프라 자원의 상태와 애플리케이션 상의 락이나 DB 내

131장. 성능이란?

저성능 쿼리 존재 여부 등과 같은 애플리케이션 상태를 종합적으로 판단해 스레드 풀 자원의 설정을

늘려줄지 또는 다른 방안을 모색할지 결정해야 한다.

이미 CPU 사용량이 90% 이상이라면 스레드 풀을 늘려봤자 무슨 소용이 있겠는가? 이때는 오히려

스레드 풀을 줄여서 CPU가 70% 내외의 안정적인 범위에 있게 함으로써 성능을 개선할 수도 있다.

각 자원의 부족 여부를 판단할 때는 다른 자원과의 상관관계와 인과관계를 잘 파악해서 평가해야

한다.

1.4.2효율성

어떤 두 시스템이 동일한 업무를 수행하지만 아키텍처 구조는 다르다고 하자. 이 두 시스템을 평가

하는 기준은 TPS와 응답시간이 핵심이겠지만 업무를 처리하면서 사용한 자원 사용량 또한 중요 평

가 기준이 된다. 동일한 TPS를 기준으로 할 때 CPU나 메모리를 적게 사용하는 시스템이 효율적으

로 작업을 수행한 것이다. 시스템 구축과 운영 시 효율성(Efficiency)은 직접적인 비용에 영향을 미

치는 요소로서 BMT(Benchmark Test) 같은 성능 비교 평가에서는 중요 평가지표가 된다.

그리고 성능 개선이라는 작업 자체가 시스템의 효율성을 높이려는 활동이다. 응답시간을 줄인다는

것은 DB 사용을 줄이고, 애플리케이션 코드의 수행시간을 줄여 시스템 자원을 더 적게 사용하도록

개선함으로써 효율성을 높이는 것이다.

1.4.3안정성

안정성(Stability)은 시스템 운영시간이 지남에 따라 성능이 저하되거나 장애가 발생하는 등의 문제

가 발생하지 않아야 한다는 것이다. 메모리나 DB 연결에 누수가 있다면 애플리케이션을 재기동하

지 않는 이상 언젠가는 해당 자원의 부족으로 장애가 발생할 것이고, 데이터가 증가함에 따라 응답

시간이 서서히 증가한다면 언젠가는 성능 저하로 사용에 불편을 느끼게 될 것이다.

시스템에 일정한 부하가 발생했을 때 시간이 지나더라도 응답시간이나 자원 사용량이 일정하게 유

지되는지 확인하는 것이 시스템 자원에 대한 안정성 평가다.

1.4.4가용성

가용성(Availability)은 일정 기간(년) 동안 시스템이 정상적으로 서비스된 시간 비율을 의미한다.

카드 승인시스템, 인터넷 쇼핑몰, 홈쇼핑 송출시스템 같은 시스템은 해당 사업에서 매출을 창출하는

1부 _ 성능 기초14

핵심 기반 시스템으로서, 장애는 사업 기회의 손실로 이어지므로 100%에 가까운 가용성을 유지하

고자 각 회사들은 이중화 구성이나 DR 구축 등에 투자하며 노력한다.

그런데 문제는 이중화만 돼 있다고 가용성이 향상되는 것은 아니라는 점이다. 서버 구성이 이중화된

경우 대부분 모든 서버를 동작 상태로 운영하므로 자원에 여유가 있어 안정적인 서비스가 가능했을

것이다. 문제는 일부 장비의 장애로 가용자원이 줄었을 때도 정상적인 서비스가 이뤄져야 한다는 것

이다. 정상적인 서비스라면 시스템에 일부 장애가 발생하더라도 사용자가 큰 불편 없이 업무 처리가

가능한 수준으로 성능이 확보돼야 한다. 그래서 가용성 테스트를 할 때 서비스 중단시간과 서비스

안정성 외에 응답시간, TPS, 자원 사용량 변화와 같은 성능지표도 함께 측정해서 평가한다.

1.4.5확장성

확장성(Scalability)은 향후 시스템 사용량 증가에 따라 시스템 증설이 필요할 때 각 자원이 얼마나

용이하게 증설될 수 있는가를 평가하는 것이다. 이것은 현 시스템 성능에 대한 평가는 아니지만 운

영 시 향후 처리량과 성능 변화에 따라 유연한 대응이 가능하도록 구성해야 한다는 측면에서 이뤄지

는 평가다.

확장성은 크게 수직 확장(Scale up)과 수평 확장(Scale out)으로 나눠서 평가한다. 수직 확장은 현

재 사용 중인 서버 내의 주요 자원을 증설해 한 서버에서 처리할 수 있는 용량을 확장하는 것이고,

수평 확장은 동일한 기능을 수행하는 서버의 대수를 늘려서 처리 용량을 확장하는 것이다. 따라서

서버 수직 확장의 경우 CPU와 메모리 증설이 가능한 빈 슬롯이 현재 사용량 대비 얼마나 남아 있느

냐가 관건이다. 수평 확장은 서버의 하드웨어적인 한계에 영향을 받는 것이 아니라 서버 내에서 동

작하는 소프트웨어가 수평 확장을 지원하느냐가 관건이다. 서버 한 대는 증설 한계가 존재하고, 초

기에 도입할 때 필요 이상으로 큰 서버를 도입하는 경우는 드물기 때문에 수직 확장은 수평 확장에

비해 확장성이 떨어지는 것으로 평가한다. 통상 DB 서버는 수평 확장에 한계가 있어 수직 확장을

주로 고려하지만 웹 서버나 WAS 서버는 수평 확장에 대한 유연성을 갖추고 있다.

2.1성능곡선

다음은 요청 사용자 수 증가에 따른 TPS 곡선과 응답시간 곡선과의 관계를 그린 그래프다.

저부하 구간

TPS 응답시간

응답시간동시 요청 사용자 수

100

20

40

60

80

100

120

140

160

20 2500.0

1.0

2.0

3.0

4.0

5.0

6.0

24023022021020014080 19013070 18012060 17011050 16010040 1509030

TPS

임계점

고부하 구간 경합 구간

[그림 1-5] 성능 곡선

저부하 구간

시스템의 처리 능력에 비해 낮은 부하가 발생하는 단계로서 시스템 자원 사용률에 여유가 있어 사용

자 수 증가에 비해 응답시간 증가는 작아 TPS가 증가하는 곡선을 그린다. 그러나 사용자가 증가하

성능특성

02장

1부 _ 성능 기초16

면서 시스템 자원에 서서히 경합이 발생함에 따라 증가율은 감소하는 추세를 보인다. 서버 CPU 자

원 측면에서는 보통 70% 미만일 때다.

고부하 구간

시스템 한계 상황은 아니나 부분적으로 부족한 자원이 발생함으로써 큐잉과 자원 경합이 발생해 사

용자 수와 응답시간이 거의 일정하게 비례해서 증가함으로써 TPS 곡선이 다소 증감을 반복하거나

거의 일정한 양상을 보인다. 성능 개선 시 최대 TPS를 높이는 것을 목표로 삼는 것이 일반적이나 고

부하 구간의 폭을 넓히는 것을 목표로 삼는 경우도 있다. 서버 CPU 자원 측면에서는 70% ~ 90%

수준일 때다.

경합 구간

시스템의 한계 상황으로 판단할 수 있다. 사용자 수 증가에 비해 응답시간이 급격하게 증가하기 시

작해 지속되면 서비스가 거의 중단되는 것 같은 현상을 보이기도 하는 단계다. 서버 CPU 자원 측면

에서는 90% 이상 수준일 때다.

임계점

TPS 곡선이 지속적인 증가가 멈추는 지점으로, 시스템의 최대 성능을 평가하는 기준이다. 위 성능

곡선에서 최대 TPS는 약 130명일 때이지만 일반적으로 임계점과 큰 차이가 없으며, 응답시간 측면

에서는 임계점이 우수하므로 이 지점을 대상 시스템의 최대 성능으로 평가한다.

일반적으로 동일한 성능 테스트 도구, 시나리오, 환경하에서 테스트를 실시하더라도 측정할 때마다

동일한 값이 측정되지는 않고 작은 오차가 있으므로 반복 테스트 시 곡선이 다르게 그려질 수 있다.

하지만 그 오차는 성능을 측정하고 평가하는 데 영향을 줄 정도는 아니다.

2.2성능에대한이해

성능은 아래와 같은 요소로 인해 복합적인 판단 기준이 필요하고 시스템 성능 기준이 달라진다.

▣ 성능은 업무와 시스템 특성에 따라 다르게 나타난다

한 시스템에 A, B라는 두 업무만 있다고 가정할 때 각 업무의 비중이 A 업무가 90%, B 업무가 10%

일 때와 A 업무가 10%, B 업무가 90%일 때 시스템의 최대 성능과 응답시간이 다르다는 것이다. 따

라서 시스템의 성능을 이야기할 때는 업무의 고유한 특성과 시나리오하에서만 논의할 수 있다.

172장. 성능 특성

그리고 동일한 사양의 장비를 사용하더라도 은행업무용이냐 보험업무용이냐와 같은 업무 특성, 그

리고 TP 기반이냐 자바 기반이냐와 같은 구축 언어, 또 어떤 프레임워크를 사용하느냐에 따라서도

성능 차이가 발생한다. 거기에 더해 개발자의 실력과 코딩 습관에 따라서도 성능 차이가 발생한다.

위의 모든 조건이 종합적으로 반영되어 나타나는 것이 바로 성능이다. 따라서 시스템 성능은 하나의

숫자로 표현될 수 있는 것이 아니다. 즉, 3초의 응답시간이나 200 TPS 같은 단일화된 숫자로 표현

할 수 없다는 것이다. 그런데 상호간에 200 TPS에 3초라는 단순한 수치로 의사소통이 된다는 것은

이미 서로가 그 수치가 기반을 두고 있는 제한 조건과 환경을 이해하고 있다는 의미가 된다.

▣ 모든 시스템에 일괄 적용할 수 있는 응답시간 기준은 없고 100% 만족시킬 수도 없다

성능 개선 업무를 지원하다 보면 프로젝트 내부에 응답시간에 대한 기준이 없는 경우가 있다. 통상

일반화면은 3초 이내, 목록 조회는 5초 이내를 권고하고, 8초를 초과하면 사용자가 지루함을 느끼

고 떠난다고 한다. 하지만 이 기준을 모든 시스템에 일괄적으로 적용할 수는 없다.

화면 구성이 비슷하더라도 업무의 성격에 따라 처리하는 데이터의 양과 로직의 복잡도가 달라진다.

그리고 사용자 충성도와 역학관계, 그리고 시장 경쟁상황에 따라 시스템 구축 시 투입되는 인적 물

적 자원이 다르기 때문에 일률적인 성능을 발휘할 수 없다.

따라서 성능 기준은 시스템 특성을 고려해 적절하고 합당하게 마련돼야 한다. 간혹 응답시간 기준을

모든 업무에 대해 100% 만족시키겠다는 목표를 두는 프로젝트가 있는데 이는 지킬 수 없는 약속을

하는 것과 마찬가지다. 단순한 몇 개의 기능으로만 구성돼 있다면 모를까 수십에서 수천 가지에 달

하는 업무를 수행하는 시스템에 대해 100% 성능 기준을 만족시키겠다는 것은 스스로 무덤을 파는

행위다. 이 경우 결국에는 응답시간을 만족하지 못하는 업무에 대해 사유를 제시하고 고객과 재합의

하는 힘든 과정을 거치기 마련이다.

▣ 동시 사용자 수가 시스템 성능을 의미하는 것은 아니다

동시 사용자 100명이 동시 사용자 10명보다 성능이 좋은 것일까? 100명일 때의 응답시간은 10초이

고 10명일 때 응답시간이 1초라면 시스템 TPS는 10으로 동일하지만 응답시간은 10명일 때가 좋다.

따라서 동시 사용자 수로 시스템 성능을 얘기할 수 없다. 웹 시스템에서 동시 사용자 수가 많다는 것

은 대부분 요청이 큐잉되고 있다는 얘기일 수도 있다. 동시 사용자 수가 의미를 가지려면 사용자가

업무를 원활하게 처리할 수 있는 성능 기준을 만족하는 상황이 전제돼야 한다.

특히 웹 기반 시스템에서 동시 사용자 수가 100,000명이라고 한다면 단지 애플리케이션 서버의 사

용자 세션 정보가 100,000개라는 것 말고는 성능에 크게 영향을 주는 요소가 없다. 그보다는 초당

1부 _ 성능 기초18

들어오는 요청 작업의 수, 웹 서버에 물리적으로 맺어진 네트워크 연결 수가 성능에 더 큰 영향을

준다.

▣ 시스템 성능은 비용과 수익으로 평가할 수도 있다

성능은 비즈니스 측면에서 트랜잭션당 비용, 이익 등으로 평가할 수도 있다. 이 평가는 시스템의

초기 구축 비용뿐만 아니라 운영 및 유지보수 비용까지 고려한 총소유비용(TCO; Total Cost of

Ownership)을 기반으로 평가한다.

시스템 자원 부족으로 목표 성능에 도달하지 못하는 경우 서버를 추가 도입하거나 부족한 자원의 증

설을 고려할 것이다. 하지만 여기에는 비용이 수반된다. 부족한 자원을 구매하는 데 드는 비용 외에

시스템 소프트웨어를 추가로 구매하는 데 드는 비용 같은 일회성 비용뿐 아니라 구매 비용 증가에

따라 유지보수 비용 증가로도 연결된다.

따라서 가장 쉬운 성능 개선 방안으로 생각할 수 있는 부족 자원의 증설이 총소유비용을 큰 폭으로

증가시키게 된다면 운영주체가 수용할 수 있는지 여부를 쉽게 결정할 수 없게 된다. 신규 시스템 구

축에 투자된 비용 이상의 수익 증가를 가져오지 못한다면 굳이 기존 시스템을 대체할 이유가 없을

것이다. 장기적으로는 시간이 더 걸릴지라도 개선될 것이라는 기대가 있다면 튜닝을 통한 성능 개선

이 효과적일 수 있다.