CPU 3%로 23,000개의 connection 처리 - Erlang과 large tcp connection

shint의 이미지

Erlang과 large tcp connection ★★★★★ [2009.04.26.]
http://cafe.naver.com/erlang/25

CPU 3%로 23,000개의 connection 처리가 가능하다고 합니다.

Rubypops의 이미지

싱글 쓰레드로 처리 하는건가요??

루비를 공부하고 사랑하는 프로그래머

shint의 이미지


OTP (The Open Telecom Platform)

OTP - Erlang - 서버

------------------------------------------------------------------------
Technically, why are processes in Erlang more efficient than OS threads?
http://stackoverflow.com/questions/2708033/technically-why-are-processes-in-erlang-more-efficient-than-os-threads

[KGC2008] 온라인게임을 위한 병행 지향 아키텍처 & 패턴 & 언어
http://www.kocca.kr/cop/bbs/view/B0000180/1289730.do?searchCnd=&searchWrd=&cateTp1=&cateTp2=&useAt=&menuNo=200953&categorys=0&subcate=0&cateCode=&type=&instNo=0&questionTp=&uf_Setting=&recovery=&option1=&option2=&pageIndex=52

마이크로소프트웨어 2008년 8월호 목차
http://knowcar.tistory.com/14316

병렬프로그래밍에서 레이스 컨디션에 대처하기 [펌] 2008.08.26.
http://blog.naver.com/kjschaos/60054536603

<웹진 140호: 인사이드 이슈> ‘얼랭(Erlang)’을 이용한 서버 프로그램 개발 https://www.software.kr/um/um04/um0403/um040301/um040301View.do?postId=8151&cpage=18

얼랭(Erlang) 웹 프로그래밍, Part 2 ErlyWeb을 이용한 웹 개발
https://www.ibm.com/developerworks/community/blogs/9e635b49-09e9-4c23-8999-a4d461aeace2/entry/207?lang=en

----------------------------------------------------------------------------
젊음'은 모든것을 가능하게 만든다.

매일 1억명이 사용하는 프로그램을 함께 만들어보고 싶습니다.
정규 근로 시간을 지키는. 야근 없는 회사와 거래합니다.

각 분야별. 좋은 책'이나 사이트' 블로그' 링크 소개 받습니다. shintx@naver.com

ddoman의 이미지

erlang도 그냥 이미유행을지나 흔해져버린 green thread 기반 async/concurrency control을 제공하는 언어 중 하나입니다.
: https://en.wikipedia.org/wiki/Green_threads

어케보면 약간 진부한 주제일 수도 있는데,

1990년대나 2000년대 초반까지도 과연 os가 제공하는 kernel-thread가 성능이 좋을것인가
또는 gnu thread같은 user space library가 제공하는 userspace-thread가 성능이 좋을것인가 토론들이 벌어졌었습니다.
하다못해, kldp만 보더라도 예전에 nptl과 ngpt중 무엇이 더 좋은성능인가에대한 글타래가 있었던것이 기억이 납니다.

결국, 쓰레드 모델의 승자는 1:1(nptl), m:n(ngpt)도 아니고, vm에 잘 녹아들은 1:m이 된듯합니다.
예전에는 gnu thread같이 C에서 구현된 user threads는 여러가지 제약사항들이 많아 널리쓰이지 못했었습니다.
왜냐면, 각각의 user thread가 자발적으로 스스로를 scheduled out했어야했기때문에, 데드락이 발생하기도 쉬웠고, 프로그램 로직이 불필요하게 복잡해졌었습니다.

이문제를 erlang이나 golang, dart-lang, 등등의 언어들에서는 문법수준에서 scheduling이 일어나고 제어하게 구현함으로써, 유저프로그램들이 자신이 직접
schedule을 다뤄야하는부분들을 최소화하였습니다.

당연히 user thread가 kernel thread보다 context-switching 비용이 훨신 적은건 너무 당연한것이고
그 언어들은 믾은 수의 동시 접속을 처리하는 서비스를 만드는데 잘 쓰여져왔습니다.

개인적으로 저런 vm들에 관심이 많아 erlang vm소스나 문서를 본적이있는데,
reactor pattern으로 I/O담당하는 I/O thread 1개내지 2개 돌리고
비지니스 로직을 수행하는 thread나 process를 보통 4~5개정도 돌렸습니다.
예전에 erlang의 쓰레드모델에 대한 글을 읽었던 기억에 의하면, 몇개의 cpu가 있냐에 따라서 erlang vm에서 생성하는 thread/process의 숫자를 제어했었던 기억이 납니다.

사실 이런식의 모델은 event-driven programming style과 너무 찰떡궁합이이기에
Node.js, Scala, Dart-lang async 구현물에도 다 쓰이고있는 모델입니다.

erlang의 가장 큰 장점은 ports와 port driver에 있다고 생각합니다.
개인적으로 dart에 관심이 많은데, dart에서도 빨리 distributed isolates와 ports를 구현했음하는 바램입니다. 2년쯤전인가 draft를 봤었던것 같은데, 아직 받아들여지진 않을듯하네요.

체스맨의 이미지

제목으로 하신 건 Erlang feature로 볼 수가 없습니다. kernel poll 의 장점인 거죠.

링크하신 문서 중 다음과 같은 내용이 있는데, 이런 정도를 Erlang의 장점으로 삼을 수 있을 겁니다.
"다른 언어로 짜면 실제 로직과 코드가 달라져서 복잡해지는 부분이 있지만 얼랭은 그대로 표현할 수 있다는 점이 가장 큰 매력이라고 한다"

Orion Project : http://orionids.org

thinxs의 이미지