티스토리 뷰
N계층 구조에서의 성능이란
N계층 서버의 성능을 클라이언트를 제외한 서버군(server farm) 전체가 상호작용하며 클라이언트의 요청을 처리하는 능력입니다. 성능을 개선하기 위해서는 각 계층 서버 용량의 총합이 아니라, 가장 낮은 성능을 가진 자원 혹은 가장 큰 병목지점에 의해 좌우되므로 이점을 유의하며 개선해야 합니다.
어떻게 튜닝할 것인가
하드웨어, 소프트웨어(서버 소프트웨어) 및 운영체제의 메커니즘을 이해해야 합니다. 또한 자료구조 및 알고리즘에 따라 성능이 달라집니다. 그리고 튜닝을 수행함에 있어서 늘 가장 좋은 효과(성능)을 얻을 수 있는 방법은 병목지점을 찾아내고, 그것을 해결하느 ㄴ것입니다. 따라서, 서버 전체의 성능을 분석하는 것 뿐만 아니라 계층 간, 계층 별 성능을 측정할 수 있는 기법을 학습/연구 해야합니다.
다양한 웹 서비스 성능 지표
웹서비스 요청에 대한 평균 응답 시간
전체 사용자 수가 증가할수록 응답 시간은 늘어날수 있습니다. 또한, 서버가 수용 가능한 임계치(threshold)를 넘을 경우, 응답 속도는 급격히 떨어집니다. 그리고 동시 요청 수, 사용자 증가, 사용자의 네트워크 위치 등 각종 조건 및 상황에 따라 가변적입니다.
단위 시간당 로그인한 사용자 수
사용자들이 늘 일정한 횟수(혹은 주기)로 서버에 요청하지 않습니다. 또한, 사용자마다 서비스 이용 패턴(활동) 이 다를 수 있습니다.
동시 사용자 수
로인 상태를 유지하고 있는(세션의 갯수) 사용자를 측정하는 기법입니다. 이말은 접속은 했으나, 실제 작업을 수행하지 않는 사용자가 존재할 수 있습니다. 웹 서비스는 사용자가 로그아웃한 시점을 파악하기 어렵습니다.(로그아웃 버튼을 클릭하지 않고 웹 브라우저를 닫는 사용자들도 많기 때문입니다.)
특정 시점에 실행 중인 서비스(요청) 갯수
서버의 자원 상황(메모리, CPU, 네트워크)에 따라 성능 편차(오차)가 발생합니다. 순간 처리량으로는 서버의 모든 성능을 평가할 수 없습니다. 예를 들어 모든 작업을 메모리를 이용해 처리하면 최대 처리량이 높아 보일 수 있지만, 처리 결과를 디스크 혹은 네트워크로 전송하기 위해서 최대 처리 성능을 보인 이후에 급격히 성능이 떨어지는 현상이 발생합니다. (이러한 현상을 PC 혹은 클라이언트 어플리케이션에서도 종종 발생합니다)
결론
사용자의 최적한 서비스 경험을 위한 "짧은 응답시간" 그리고, 서버의 안정적인 운영을 위한 "적절한 처리량"이 가장 중요한 성능지표라 할 수 있겠습니다.
송수관 이론
N계층 서비스 상에서 서버를 송수관에 비유할 수 있습니다. 송수관의 성능을 판단하는 가장 이상적인 기준은 관의 굵기(크기), 물의 압력(펌프의 종류)이 아니라, 단위 시간 당 흘려 보낼 수 있는 수량입니다. 수량(성능)은 유속과 송수관 단면의 면적에 비례합니다. 유속은 펌프의 종류에 따라 결정되며, 단면의 면적은 파이프 반지름의 제곱에 비례합니다. 이를 서버에 적용하면 펌프의 종류는 'CPU의 유형', 단면의 면적은 '메모리의 크기와 네트워크 속도'에 비유할 수 있습니다. 웹 서비스의 성능은 응답 속도만을 판단해서는 안되며, 단위 시간 당 처리량(throughput)을 중요한 지표로 판단해야 합니다.
TPS vs Mean ResponseTime
평균응답시간(Mean ResponseTime)
시스템의 처리능력 한계치보다 낮은 동시 사용자가 접속할 경우에는 일정한 수치를 유지하지만, 한계치를 넘게되면 사용자 수에 비례해서 느려지게 됩니다.
단위 시간 당 처리 건수(Transaction Per Second)
동시 사용자가 계속 증가해도 최대값 보다 증가하지 않는다. 따라서 서버 성능 측정 기준으로 단위 시간당 최대처리 건수를 의미하는 TPS를 사용하는 것이 적합합니다.
서버의 동시 처리량 이해
깔대기 이론(Funnel theory)
서버가 클라이언트의 요청을 처리하는 매커니즘은 깔대기를 이용해 물을 흘려보내는 행위에 비유할 수 있습니다. 깔대기로 흘러내리는 물은 웹 서버에 도달하는 요청(request), 아래로 빠져 나가는 물은 응답(response), 깔대기 내에 머물러 있는 물은 처리중인 작업(processing or job)입니다. 머물러 있는 물의 양은 '동시 처리 서비스 개수(concurrent processing service count)'입니다. 만일, 점진적으로 요청 건수가 늘어날 경우, 동시 처리량이 늘어날 것이며 서버가 처리할 수 있는 한계를 넘게 되면 오버플로우(overflow)현상이 발생합니다. 이 때, 서버의 처리(혹은 구현)방식에 따라 일부 요청에 대해서 정상적으로 응답하지 못하거나(does not respond), 서버 자체가 멈추는 현상(hang-up)이 발생합니다.
Lock
Lock이 주는 영향
Involuntary Context Switch, CPU pipeline 훼손이 있으며, Lock은 기본적으로 비싼 CPU Operation입니다.