웹사이트의 이용이 가장 많을 때가 마치 출퇴근 시간 도로 정체 때와 비슷하게 보이기 시작한다면 그것은 무언가 조치가 필요하다는 의미다. 무거운 부하를 처리하는 데 필요한 대역폭, 전력, 속도, 혹은 효율성이 업는 웹 인프라는 실망한 사용자들을 통째로 보내버릴 것이다. 문제의 원인을 파악하기 위해서는 사이트의 종단간 성능을 테스트할 필요가 있다. 그런 후에는 웹사이트의 정체 현상이 웹 서버에 충분한 프로세싱 파워가 없어서인지, 라우터가 너무 느려서인지, 아니면 다른 어떤 병목 지점이 있는지를 알 수 있을 것이다.

벤치마킹을 시작하기 전에, 테스트를 통해 얻고자 하는 정보가 무엇인지를 결정해야 한다. 웹사이트가 45Mbps를 처리할 수 있는지 여부는 확인할 필요가 없다. 한 명의 사용자도 이론적으로 45Mbps를 당겨올 수 있기 때문이다. 그보다는 테스트하기 어려운 상황들을 고려하라. 즉 사이트가 1만명의 동시 사용자를 처리할 수 있는가, 5천명의 사람들이 데이터베이스 질의를 하고 있을 때 한 사용자가 페이지 하나를 다운로드하려면 얼마나 기다려야 하는가 등을 알아보아야 한다.

어떤 정보를 얻고 싶은가

종단간 성능 측정에 유용한 테스트를 기능성 검사(functionality verification)라고 한다. 이것은 다운로드된 웹페이지가 제대로 된 것인지 아니면 잘못된 페이지인지를 확인해주기 때문에 웹 서버가 데이터베이스 서버에 도달할 수 없을 때를 탐지할 수 있다. 서버가 100만개의 접속을 처리할 수 있음을 아는 것은 좋지만, 그 접속들 중 40%에 SQL 에러 메시지가 포함돼 있다면 문제가 있는 거다.

웹사이트 테스팅에서는 가능한 한 실제에 가까운 트래픽을 사용하는 게 좋다. 전형적인 페이지를 다운로드하거나 다중 데이터베이스 입력 및 질의를 실행하라. 예를 들어 콘텐츠가 그리 문제가 되지 않는 곳에서 레이어 4 방화벽 테스트를 하고 있지 않는 한 단순히 TCP를 ‘열기’와 ‘닫기’로 초기화하는 것만으로는 충분치가 못하다. 그러나 레이어 7 지각 장비를 테스트하고 있다면 실제 데이터가 필요하다.

테스트를 실제에 가깝게 하기 위해서는 사용자 행동도 또한 시뮬레이팅해야 한다. 사이트를 돌아다니고, 다중 작업을 수행하고, 얼마간의 ‘생각하는 시간’도 고려하라. 한 사용자가 복잡한 웹 양식을 다운로드해서 그것을 작성하고 제출하는 데는 1초 이상의 시간이 걸리기 때문에 양식을 제출하기 전에 몇 초나 1분을 추가해야 정확한 재현이 될 수 있다.

테스트를 위해 제대로 된 벤치마킹 툴을 선택하는 것도 쉬운 일은 아니다. 이들은 기능과 가격대가 매우 다양하기 때문이다. 어떤 경우에는 벤치마킹 하드웨어와 소프트웨어를 모두 구입해야 할 때도 있을 것이다. 셰어웨어, 프리웨어 및 칩웨어 벤치마킹 툴을 시도해볼 수도 있지만, 여기에는 필요한 기능들이 빠져 있다.

실제와 같은 테스트로

실제에 가까운 테스트에는 또한 여러 가지 유형의 트래픽과 사용자 스크립트로 인해 흔들리는 시작 시간 등도 포함돼야 한다. 어떤 프로토콜을 테스트하느냐는 사이트에서 제공하는 서비스 종류에 따라 달라진다. 웹 테스트에서는 HTTP와 HTTPS만이 필요하겠지만 레이어 7 방화벽을 갖고 있고 네트워크에서 가장 자주 사용하는 것이 HTTP, FTP, DNS 및 SMTP라면 이런 모든 유형의 트래픽과 함께 방화벽을 테스트할 필요가 있다.

그리고 존속 가능한 트래픽을 테스트하는 게 좋은데, 그 이유는 시간이 지나면 트래픽이 치솟기 때문이다. 이렇게 하면 테스트 받고 있는 장비는 전복되지 않을 것이며 오류가 나기 이전에 장비의 최대 용량을 알 수 있게 된다. 따라서 100개의 접속부터 시작해서 500개, 1천개로 진행시켜 가야 한다. 트래픽은 교대로 사이트에 도달할 것이다(어떤 것들은 핸드셰이크가 되고 나머지는 데이터 전송 및 세션 종료가 될 것이다).

1초안에 접속된다고 보장하면서 수맥 만 개의 접속이 동시에 이루어지는 사이트는 없겠지만 갑작스런 스파이크(spike)의 가능성을 배제해서는 안 된다. 스파이크 테스트를 위해서 신규 접속 비율을 갑작스럽게 높여라.

사이트가 지원할 수 있는 일관된 속도의 계산은 테스트 정의에 따라 달라진다. 최대 TCP 접속 수를 테스트하고 있는가, 아니면 최대 사용자 수를 테스트하고 있는가. 한 사용자가 동시에 여러 개의 TCP 세션을 가동시키거나 한번에 단 하나의 TCP 세션으로 웹사이트를 돌아다니거나, 혹은 TCP 세션을 전혀 열지 않고 아주 짧은 시간동안 머무를 수도 있다. 이들이 긴 텍스트 페이지를 읽는가, 아니면 금방 다른 페이지로 넘어가는가.

웹 서버 테스트는 존속 가능한 TCP 접속과 초당 겟츠(gets) 수, 그리고 응답 시간의 조합을 수집해야 한다. 초당 겟츠 수는 하나의 사용자 세션이 얼마나 빨리 실행될 것인지를 알려준다. 이런 요소들은 테스트하기가 까다로울 수 있다. HTTP 1.0 대 HTTP 1.1 프로토콜에서의 차이를 고려해 보라. HTTP 1.1 버전은 ‘keepalives’를 지원하기 때문에 하나의 접속만 필요하지만 버전 1.0에서는 그 페이지에 있는 모든 요소들에 대해 하나의 접속이 필요하다. 이전 브라우저들은 1.0을 사용하기 때문에 사이트가 지원하게 될 최대 사용자 수를 결정할 때 이를 염두에 두어야 한다. 여기서 가장 안전한 방법은 1.0과 1.1 HTTP 트래픽을 섞어서 테스트하고 벤치마크 툴이 메인 페이지만이 아니라 전체 객체를 풀 다운하도록 하는 것이다.