굉장히 어려운 구조이군요. nGrinder 는 Async Call 을 하는 시스템에 대해 성능 테스트가 힘듭니다. 그 이유는 Recording 을 한 메소드가 실행될때 TPS가 증가되는데, 이때 메소드가 실행되는 쓰레드에 따라 쓰레드별로 각자 Call 횟수를 수집합니다. 그러나 Async Client 라이브러리의 경우, 메시지가 수신을 대기하는 쓰레드가 테스트가 실행된 쓰레드와 다른 쓰레드이므로, nGrinder 에서는 해당 콜은 테스트에 의해 실행된 것이라고 판단하지 않아 TPS가 올라가지 않습니다.
이를 해결 하기 위해서는 Latch 를 사용하여 테스트 쓰레드가 Vert.X 쓰레드에 따라 대기 / 재시작이 되도록 구현해 주셔야 합니다. 상당히 어려운 부분이나, 유사한 Async Call인 Socket.IO 쪽 예제는 다음에서 보실 수 있습니다. 비록 Jython으로 구현되어 있긴 하나 어떤 아이디어로 앞서 말씀 드린 쓰레드간 제어를 수행하는지 확인하실 수 있습니다.
http://www.cubrid.org/wiki_ngrinder/entry/using-ngrinder-to-perform-load-test-for-a-socket-io-app