안녕하세요,
jmeter로 tcp서버 성능 테스트를 하기 위해서 관련 내용을 검색하다가 찾아오게되었습니다. 그동안 jmeter로 http로직을 테스트하는 경우는 종종 있었지만 자신의 직접 패킷의 형태를 정의한 tcp서버 벤치마크는 이번이 처음인 상황이었는데 이 프로젝트를 통해 beanshell작성과 커스텀 플러그인 작성하는 부분에서 많은 도움을 얻게 되어서 혹시 추후에 이 소스를 사용하시는 또다른 분께 제가 겪었던 사소한 문제 상황을 글로나마 남겨서 도움을 드리고자 합니다~
제 경우에는 클라이언트에서 2kb 크기의 전문을 날리면 서버가 그대로 리턴해주는 에코서버 형태의 테스트를 진행하였는데요,
현재 이 프로젝트의 beanshell에서는 string데이터를 자신이 정의한 프로토콜에 맞는 형태의 패킷으로 만들고, 그 패킷을 헥사코드 문자열로 변환한 뒤, 헥사코드 문자열을 DynamicLengthTCP클래스에서 다시 바이너리로 변환하여 서버로 전송하는 형태로 구성되어있습니다.
이 부분이 제 경우에는 jmeter쪽 보틀넥이 되었습니다. 패킷의 크기가 작은 경우에는 체감하기 어려울 지 모르나, 제 경우에는 2kb정도 되는 전문을 송수신하는 벤치마크 로직이다 보니 바이너리<->헥사코드 변환하는 부분에서 jmeter보틀넥이 상당했었습니다. 저는 이 변환로직을 제거하여 보틀넥을 해소하였는데요, 다른분들께서도 이 부분을 주의하시면 좋을 것 같습니다~ 감사합니다.
안녕하세요,
jmeter로 tcp서버 성능 테스트를 하기 위해서 관련 내용을 검색하다가 찾아오게되었습니다. 그동안 jmeter로 http로직을 테스트하는 경우는 종종 있었지만 자신의 직접 패킷의 형태를 정의한 tcp서버 벤치마크는 이번이 처음인 상황이었는데 이 프로젝트를 통해 beanshell작성과 커스텀 플러그인 작성하는 부분에서 많은 도움을 얻게 되어서 혹시 추후에 이 소스를 사용하시는 또다른 분께 제가 겪었던 사소한 문제 상황을 글로나마 남겨서 도움을 드리고자 합니다~
제 경우에는 클라이언트에서 2kb 크기의 전문을 날리면 서버가 그대로 리턴해주는 에코서버 형태의 테스트를 진행하였는데요,
현재 이 프로젝트의 beanshell에서는 string데이터를 자신이 정의한 프로토콜에 맞는 형태의 패킷으로 만들고, 그 패킷을 헥사코드 문자열로 변환한 뒤, 헥사코드 문자열을 DynamicLengthTCP클래스에서 다시 바이너리로 변환하여 서버로 전송하는 형태로 구성되어있습니다.
이 부분이 제 경우에는 jmeter쪽 보틀넥이 되었습니다. 패킷의 크기가 작은 경우에는 체감하기 어려울 지 모르나, 제 경우에는 2kb정도 되는 전문을 송수신하는 벤치마크 로직이다 보니 바이너리<->헥사코드 변환하는 부분에서 jmeter보틀넥이 상당했었습니다. 저는 이 변환로직을 제거하여 보틀넥을 해소하였는데요, 다른분들께서도 이 부분을 주의하시면 좋을 것 같습니다~ 감사합니다.