본문 바로가기

카테고리 없음

뜬 구름 잡는 부하테스트

보통 연인들끼리 옛날에 자주하던 말로 내 저 별도 너에게 따줄 수 있어~ 란 표현을 쓰곤 한다. 또는 하늘에 뜬 구름 잡기처럼 애매모호하단 표현을 쓰곤 한다.

요즘 부하테스트를 하면서 이런 표현이 딱 알맞다는 생각을 했다. 배일 속에 가려진 실체라도 점점 드러내는 맛이 있으면 좋겠지만 실체를 드러내기는커녕 뜬 구름이라 도통 잡히지 않아 화만 날 지경이다.

일단 이정도 서버 스펙에서 어느 정도의 세션을 견뎌야 정상인지 정확한 기준을 모르겠다. 예를들어 인텔 쿼드코어 4Ghz에 4G 메모리라 50,000세션을 견뎌야 한다면, 그렇게 말할 수 있는 근거는 무엇인가. 예전에 비슷한 사양에서 50,000세션을 견뎠기 때문인가.

비슷한 얘기로 부하테스트 결과 10,000세션을 견뎠는데 이 상황이 지금 서버 스펙에 맞게 잘 버틴건지 아직 튜닝의 여지가 남았는지 판단근거가 애매모호 하다.

무엇보다 부하테스트 중 원하는 만큼의 결과가 나오지 않았을 때 어디서부터 잘못 됐는지 알기 어렵다. 서버 스펙 자체가 낮아서 그런지, 아파치가 잘못됐는지, JBoss가 잘못됐는지, 프레임워크가 잘못됐는지, 부하테스트 툴 자체가 잘못됐는지 추적하기가 어렵다.

내가 이렇게 뜬구름 잡는 이유는 부하테스트와 튜닝에 대한 지식이 부족한 것에 있다. 내가 위에 제기한 의문이 전문가 입장에서는 사실 쉽게 답할 질문일수도 있다. 그렇다고 관련 문서, 무엇보다 잘 정리된 책을 찾았는데 그런 책도 못 찾겠고, 한마디로 군대에서 무대뽀로 축구하는 그런 느낌이다.

그 와중에 좌충우돌 하며 조금씩 실체에 접근하기는 했다. 예를 들어 테스트 대상이 넓게 펼쳐져 있을 때, 서버, 아파치, JBoss, 통신모듈을 동시에 테스트 한 결과가 좋지 않다면, 단순 HTML만 호출하여 서버, 아파치 구간까지만 부하테스트 한다. 그러면 일단 서버, 아파치에서 견디는 최대 용량을 알 수 있으니 이 데이터를 기준 삼아 다음 테스트를 이어갈 수 있을 것이다.

하지만 정식으로 배운것도 아니고, 전문 부하테스트 툴도 있는 것도 아니고, 전문가의 도움을 받는 것도 아니고, 관련 책도 문서도 찾기 힘든 상황에서 삽질하자니 답답하다.

오늘은 IBM developerWorks에서 ‘테스트’란 검색어로 검색된 기사 목록을 링크로 남긴다.

IBM developerWorks 테스트 관련 기사