삼성위주

LG

SKY

기타

헥헥

320을 기본으로 480 (540포함), 720(800포함) 3가지 해상도를 신경 많이 쓰면 될듯.

CPU 는 1GHz 기준으로 (HTML5 Canvas 는 돌리기 어려움) 보고,

장비스펙 (KT cloud 장비임)
- CPU : 2 x vCore (E5640 @ 2.67GHz 로 나오네요)
- RAM : 2GB
- DISK : 기본제공

기본적으로 웹장비는 LB하에 있고 1ea에 대해서만 서술하자면,

concurrent : 300 일때 vmstat -n 5 정보 (concurrent 는 netstat -an | grep ":80" | wc 기준 입니다)

아주 널널 합니다.

php process 는 persistent connection 으로 memcache 와 db에 연결 됩니다.
php-fpm.conf 를 보면 pm = static 이고 pm.max_children = 48 입니다. max_children 의 경우 숫자를 32 정도 부터 300 까지 테스트 해 보았으나 특정 수 이상에서는 성능향상이 없었습니다. 그래서 그당시 (1년이 넘었네요) 내린 결론이 backend response (db나 기타등) 가 느려져서 48개 프로세스 모두 busy 라면 backend 를 개선할 문제지 프로세스를 늘려 추가적인 문제나 리소스를 낭비할 문제가 아니다 라는 결론으로 정한 숫자입니다.
그리고 이렇게 child 를 제한하면 backend 데몬에 대한 connection pooling 에 대해서 좀 자유로울 수 있습니다. (설정상으로라면 웹서버를 10개를 써도 480개 밖에 안되죠...)

lighttpd.conf 의 일부를 보면

server.modules = ( "mod_accesslog", "mod_fastcgi", "mod_redirect", "mod_proxy", "mod_compress", "mod_setenv" )

server.event-handler = "linux-sysepoll"
server.network-backend = "linux-sendfile"
server.max-fds = 30720
server.max-connections = 5120

# 서비스용
server.max-keep-alive-requests = 1024
server.max-keep-alive-idle = 5

fastcgi.server = (
".php" =>
(
(
#"socket" => "/****/phpfastcgi.sock"
"host" => "127.0.0.1",
"port" => 9001
)
),
"/lp_server" =>
(
(
"socket" => "/****/lp_server.sock",
#"host" => "127.0.0.1",
#"port" => 9002,
"bin-path" => "/****/lp_server /****/lp.conf",
"max-procs" => 4,
"check-local" => "disable"
)
)
)

참, PHP 스크립트는 대부분 read 보다는 insert, update 를 주로 합니다. ad-hoc query 를 사용하여 스크립트 마다 수행되는 query 수를 상당히 많은 편 이구요.

backend db나 memcache 서버는 분리 되어 있으며 대략 db는 8 vCore, 4GB , memcached 는 다른 용도도 겸 하면서 2 vCore, 2GB 입니다.

또 한가지, CPU 사용량이 상당히 적은 편인데요. PHP 어플리케이션의 특성상 렌더링을 하지않고 json format 으로만 output 합니다. 그래서 output traffic 도 상당히 적다죠.

이렇게만 적어도 아실 분은 많으므로...
 

채팅이 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 귀찮아서 대충씀.