채팅이 Ape를 기반으로 구성되어 있었는데 (이미 1년전 부터 운영중) 1.0 버전대에서는 메모리릭으로 인해서 swap 메모리까지 다 쓰고 죽는 현상이 있었고,
1.1 버전대로 업한 후에는 메모리릭은 개선되었으나 유저 disconnect 타이밍때 절묘하게 중복 free 비슷한 현상으로 인해 세그먼트 폴트 현상이 있었다.
1.1 버전을 수정해 보려 했으나 Ape 소스 수정이 까다롭다는 개발자의 의견이 있었다
해서 nodejs 의 강력한 모듈인 socket.io 를 사용해서 채팅서버를 개발하게 되었고 일주일만에 뚝딱 개발해서 Ape 모듈을 교체 하였다.
교체하고 기존 것과 비교를 하니
Ape를 long-polling 으로만 사용하고 있었고,
Socket.io 는 websocket, flash-websocket, long-polling 순으로 핸드쉐이크를 하게 설정을 해 뒀는데
장단점을 보면
1. Ape는 확실히 long-polling 인데도 불구하고 CPU 점유율이 극히 낮다. (예전 2천명 가량 접속했을때도 미동도 하지 않았던 것으로 기억)
2. Ape는 1번 말고는 Socket.io 에 비해 장점은 없다.
3. Socket.io 는 websocket 사용으로 인한 트래픽 감소 (Ape 때는 in-out bound 트래픽의 거의 비슷, Socket.io 교체 후에는 in bound 는 미비, oout bound 는 유지, 합산하면 크게 차이남), websocket 사용으로 인한 반응속도 향상
4. Socket.io 는 CPU 많이 먹고 G-C 때 CPU 를 좀 더 많이 먹는다. (평소 1%이하, G-C때 20% 에서 와따가따, 동접 1천 정도)
5. websocket 사용으로 인해서 avast 백신이 깔린 환경에서 동작하지 않거나 하는 미동작 유저가 다수 발생. (크롬+Avast 면 Avast가 websocket 요청을 drop 시킴) - 역시나 인프라 측면에서 웹소켓은 아직 준비가 덜 되었는듯한 느낌.
결론은 multi-process 기반한 nodejs 를 프로젝트 전면에 사용할 예정이라능.
결론2 귀찮아서 대충씀.
1.1 버전대로 업한 후에는 메모리릭은 개선되었으나 유저 disconnect 타이밍때 절묘하게 중복 free 비슷한 현상으로 인해 세그먼트 폴트 현상이 있었다.
1.1 버전을 수정해 보려 했으나 Ape 소스 수정이 까다롭다는 개발자의 의견이 있었다
해서 nodejs 의 강력한 모듈인 socket.io 를 사용해서 채팅서버를 개발하게 되었고 일주일만에 뚝딱 개발해서 Ape 모듈을 교체 하였다.
교체하고 기존 것과 비교를 하니
Ape를 long-polling 으로만 사용하고 있었고,
Socket.io 는 websocket, flash-websocket, long-polling 순으로 핸드쉐이크를 하게 설정을 해 뒀는데
장단점을 보면
1. Ape는 확실히 long-polling 인데도 불구하고 CPU 점유율이 극히 낮다. (예전 2천명 가량 접속했을때도 미동도 하지 않았던 것으로 기억)
2. Ape는 1번 말고는 Socket.io 에 비해 장점은 없다.
3. Socket.io 는 websocket 사용으로 인한 트래픽 감소 (Ape 때는 in-out bound 트래픽의 거의 비슷, Socket.io 교체 후에는 in bound 는 미비, oout bound 는 유지, 합산하면 크게 차이남), websocket 사용으로 인한 반응속도 향상
4. Socket.io 는 CPU 많이 먹고 G-C 때 CPU 를 좀 더 많이 먹는다. (평소 1%이하, G-C때 20% 에서 와따가따, 동접 1천 정도)
5. websocket 사용으로 인해서 avast 백신이 깔린 환경에서 동작하지 않거나 하는 미동작 유저가 다수 발생. (크롬+Avast 면 Avast가 websocket 요청을 drop 시킴) - 역시나 인프라 측면에서 웹소켓은 아직 준비가 덜 되었는듯한 느낌.
결론은 multi-process 기반한 nodejs 를 프로젝트 전면에 사용할 예정이라능.
결론2 귀찮아서 대충씀.
Trackback Address :: http://gitagy.tistory.com/trackback/57
