회사에서 Node.js + Express 로 돌고 있는 서버의 퍼포먼스를 측정하는 일을 했었다.

실제로 큰 소득이 있지는 않았지만 그 과정에서 깨닫게 된 (당연하게 보이는) 것들을 정리해보았다.

EC2 C5.xlarge 기준 Express 1 프로세스 (1 core) 의 이론적 Request Per Sec 한계는 4000 정도 인듯 링크

해당 사항은 실제로 http 프로토콜 상 문제가 아닐까 생각한다. 패킷 까는 데 많은 자원을 소모하는 것 같다.

해당 도메인에서 사용하고 있는 가장 빈번한 시나리오로 테스트 해보아야 한다.

당연한 내용인데, 정작 일하면서 깨닫는 데엔 2일 정도가 걸림. 나무를 보다가 숲을 못 본 케이스.

로컬에서 스트레스 테스트를 날릴 땐 소켓 한계 잘 생각하자. Keep-Alive 조건을 주는 것은 거의 필수인듯 링크

로컬에서 포트를 계속 열게 되면 65535 를 넘어가서 소켓 행업이 되어 테스트 자체가 되지 않는다.

concurrent 유저가 높아질 때 어느 순간부터 latency 가 증가하는 이유는 RPS 한계 때문에 당연히 그럴 수 밖에 없다. 따라서 목표 latency 를 설정하고, 그에 맞춰 horizontal scaling 정책을 수립해야 함.

생각해보면 당연한 사실인데, 이러한 사실을 깨닫는 데에 시간이 오래 걸렸다. ㅋㅋㅋㅋㅋㅋㅋ

V8 최적화 도 생각해야 한다.

Node 환경에서 JIT 컴파일을 하기 때문에 해당 부분이 Bottleneck 일수도 있다.

Conclusion

• Node 용 프로파일러 0x 를 사용하여 프로파일링도 했지만, 노드 특성상 콜스택이 날라가버리기 때문에 제대로 된 분석을 하기는 힘들었다.
• 퍼포먼스 테스트 어렵다. 일단 도메인에 맞는 테스트를 잘 정의해야 하고, 환경도 비슷하게 세팅하거나 환경이 달랐을 때의 영향을 고려해야 한다.

퍼포먼스 테스트와 병목 지점을 잘 찾아내기 위해선 네트워크 레벨에서부터 컴파일러와 OS의 동작까지 이해를 하고 있어야 가능할 거 같다. 아직 엔지니어로써 갈 길이 멀다는 것을 알게 된 소중한 시간(?)이긴 한 듯.