Lies, Damn Lies and Benchmarks.

Lies, Damn Lies and Benchmarks.

란 클리셰가 나오게 된 원인은

사람들이 트레이드오프랑 전제조건을 같이 인용하지 않기 때문이다.

 

Advertisements

싱글스레드 모델이 액터 모델(Actor-Model)보다 나은 X가지 이유

1. 액션(동작) 순서 컨트롤이 된다. 액션의 페이스를 컨트롤할 수 있다. 예를 들어 30fps 로 모든 몹의 x좌표 더하기 1. 액터 모델에서는 비동기라서 그 액션이 어느 프레임에 들어갈찌 모른다.

2. 디버깅이 쉽다.
2.1 액터 모델에서는 글로벌 상태에 브레이크 포인트를 찍은 후에 매개인의 메일박스를 검사해야 하는 번거로움이..
서버의 경우 클라와 달리 브포보다 로그가 더 유용할 경우가 많다. 예를 들어서 Joe Armstrong 과 Richard Stallman 등 분들이 모두 printf 디버깅 방식을 더 선호한다는 소문이… 하지만 서버가 클라만큼 상태가 복잡할 경우, 브포(==시간정지) 를 통한 글로벌 상태 파악이 극히 중요해질 때가 있다.
2.2 그리고 액터 모델은 비결정론적이라서 어떤 버그들이 어떤때는 재현되고 어떤 때는 재현되지 않을 수 있다. (그러고보니 2.2 항목은 LMAX 의 장점만 말하면 다 나오네.)

3. 반경 10메터안 모든 몹들에게 범위공격. 액터모델의 경우 남의 좌표를 알 수 없어서 일일이 물어야 한다. “님 좌표 얼마임?” (그렇지 않으면 좌표를 좌표테이블에 등록해야 하는데, 그러면 액터모델이 아니게 됨) (IO 오버헤드, 코딩 코스트)

4. 로드밸런싱따위 필요없다. 액터모델의 경우 (스케쥴러에 따라 다르지만) (어차피 스케쥴러 연구하는 사람은 없으니) 액터 로드밸런싱이 필요한 경우가 있다(Skynet 역사 참조). 반면 싱글스레드 모델에서 프로그래머는 신이고, 로드밸런싱따위 필요없다.

5. 트랜잭션?

6. 클라도 싱글스레드 모델이잖아.

7. CPU 성능에 좋다 (동일언어) (사실 이건 가장 중요하지 않은 원인이다) (늘여쓰면 글한편감이라 자세한 내용은 생략한다).

결론: 두 모델이 서로 다른 문제 도메인 (Problem Domain) 에 적합할 것 같다는거다:

  • 액터모델은 격리성, 분산성과 faul-tolerance 가 골(goal)에서 제일 중요한 경우 또는 message-passing 자체가 문제를 잘 모델링할 경우 (IM, Instant Messenger: e.g. Facebook Messenger, Whatsapp, etc.)
  • 싱글스레드 모델은 글로벌 상태 컨트롤이 중요한 경우. 예를 들어 게임. (시뮬레이팅 문제?)

적재적소(適材適所).

길게 쓰면 아무도 안읽으니 이번에도 후딱 끝내는 미덕을 발양하겠다.

(끝)

한눈에 보는 MQ

  • coolspeed

요즘 MQ에 빠져 MQ덕질 좀 했습니다.
길게 쓰면 아무도 안읽고, 쓰는 사람도 귀찮아지니 알맹이만 적겠습니다.

ActiveMQ – 정통 MQ, 기능 많음, 트랜잭션 지원.

RocketMQ – 알리바바에서 오픈한 MQ. 지구상 가장 분주한 전자상거래 시스템중 하나인 알리바바의 인프라로 매일 높은 워크로드에서 사용되고 검증되고 있음. 세계 기록을 갱신한 쇼핑몰 오더 처리 성능.

Java로 개발됨. 활발한 개발과 (중국내) 활발한 커뮤니티. 트랜잭션 지원(그러니 전자상거래에 쓰일 수 있지).

단점: 클라이언트 언어는 Java 와 C++ 만 지원.

Apache Kafka – LinkedIn 에서 오픈. Scala 언어로 개발됨. 개발팀은 나가서 새로 회사를 차렸다는데 현재는 개발과 커뮤니티가 모두 그다지 활발하지 않음.
최대 장점은 성능. 특히 batch 모드를 켰을 때 (redis pipeline모드랑 유사).
단점: 트랜잭션 지원하지 않음.

RabbitMQ – Erlang 으로 개발됨. 성능 좋음. (거의) 모든 언어 클라이언트 제공.
AMQP의 여러 기능을 지원하는 만큼 ActiveMQ에 버금가는 다양한 피쳐.
Erlang으로 개발된 만큼 fault-tolerance 가 짱임.

ZeroMQ – 사실은 MQ가 아님. Zero * MQ == zero != MQ?
네트워크 라이브러리? 네트워크 프로토콜 스택상의 새로운 레이어? Linux커널에 들어가는 것을 목표로 한다.
끊기면 자동 재연결하는 고급 소켓. Listen 과 accept 순서 무관인 고급 소켓.

(거의) 모든 언어 클라이언트 제공. 라이트한 만큼 성능이 장점.

“ZeroMQ” 에서 “Zero”는 broker가 없음을 의미. 그만큼 분산식 차원에서 더욱 철저하다.

(무엇보다 얘는 정말 MQ가 아니기에 MQ리스트 안에 넣어서 비교하는 자체가 어색하다. MQ같은 네트워크 라이브러리.)

차세대 Go언어 게임서버 Century 뼈대

소스코드 주소: https://github.com/coolspeed/century

Amazon Gamelyft 때문에 맥나서 안짤려다가 블로그글 에서 쳐놓은 허풍들이 죄가 되여 끄적여보았습니다.

일단 현재는 실행 가능한 채팅서버이구요.

벤치마크결과는 8만5천 TPS 씩이나 나와서 벤치마크 프로그램을 의심하는 중입니다.

그 어떤 비평도 다 저에게 다 도움이 될 것이니 어떤 비평이든 아끼지 말고 주시기 바랍니다.
(라고 쓰고 “칭찬과 좋은 비평만 듣겠다” 라고 읽는다.)

매니지드 언어로 MMORPG 만들기

사건의 유래는 게임코디에 어느분이 이런 질문을 올린겁니다.

MORPG까지는 만들어봤는데, 심리스한 MMORPG를 Java나 C#으로 ( 메이저 한 언어로 갑시다…! ) 만든다고 하면 막연히 가장 걱정되는게 Full GC 상황에서의 world stop입니다. 아무리 concurrent gc나 vm 옵션을 건드려서 최적화 한다고 해도 언젠가는 Full GC를 마주칠텐데 1초만 world가 멈춘다고 해도 썩 유쾌한 경험은 아닐거 같거든요.

두번째로는 최대가용 메모리 입니다. Full GC랑 연관이 있는데 결국 Full GC상황에서의 GC 수행시간은 vm에 할당한 최대 heap size에 어느정도 비례합니다. 이 주제를 놓고 지인들과 몇번 토론을 했는데 주로 나온 얘기들은…

‘마영전은?’
‘누가 시도해 본 사람?’
‘요즘 하드웨어 좋은데 괜찮지 않을까?’
‘C++ 놓은지 너무 오래되서…(?)’
‘최소화 할 수는 있겠다, 죄다 pooling 한다던가, 그런데 적당히 해야지 이럴거면 왜 java나 c#을 써야할까?’

와 같은 얘기 -_- 어떻게 생각하시나요?

Continue reading