온라인게임 플랫폼의 두 흐름 '리눅스 서버vs윈도 서버' - 그라

zupet의 이미지

안녕하세요. 매크로 없는 메비~랍니다.

지인으로 부터 재밌는 링크를 받았네요. 일단 링크 와 함께 게시물을 등록합니다. 제가 아는 바로는 리눅스가 조금 더 다양한 가능성이 있다고 하는데 국내 5대 게임업체의 기술이사님은 조금 다른 생각인가 보네요.

http://www.etnews.co.kr/news/detail.html?id=200408160048&keyword=

Quote:
온라인게임 플랫폼의 두 흐름 '리눅스 서버vs윈도 서버'

IMF를 전후로 국내 게임업계에 ‘온라인 게임’이라는 새로운 조류가 급부상하기 시작했다. 특히 온라인 롤플레잉 게임은 전국의 게임방 열풍과 정부의 IT지원 정책에 힘입어 양적, 질적으로 급격히 성장했다. 온라인게임은 싱글플레이 게임에서는 맛볼 수 없었던 요소가 있다. 바로 사람들끼리의 협력과 경쟁이다. 온라인게임 세상은 마치 사회 축소판과 같기 때문에 어떤 게임보다 감정이입이 강하다. 온라인게임 개발에서 중요한 것은 서버 플랫폼이다.

 현재 온라인게임 전신인 머드게임(MUD Game)의 서버 플랫폼은 선(Sun)사의 Solaris 혹은 HP/UX 등 유닉스 플랫폼(UNIX Platform)이 대부분이었다. 이후 리눅스 바람과 월드와이드웹(WWW) 열기에 힘입어 리눅스 기반 서버 개발이 널리 연구되고 사용되기 시작했다.

 온라인게임 서버는 크게 리눅스 서버와 윈도 서버로 구분된다. 리눅스 서버와 윈도 서버의 장단점을 비교해보고 최근 각광받고 있는 리눅스 서버의 기술 동향에 대해 살펴본다.


 ◇리눅스 플랫폼=리눅스의 장점이라면 무엇보다 무료라는 점과 모든 소스가 공개되어 있다는 점이다. OS의 구조나 운용 자체가 투명하게 공개돼 있기 때문에 시스템의 깊은 부분까지 핸들링해야 하는 서버 개발자에게는 더 없이 좋은 환경이다. 또한 많은 서버 개발자들은 실제로 서비스를 하게 되는 머신(Machine)에 설치된 OS가 자신이 제작한 게임 서버의 전용 OS처럼 동작하기를 희망한다. 온라인게임 개발자의 경우, OS에서 필요없는 부가기능을 다 제거하고 오직 게임 서버 동작을 위한 기능만을 원하는 경우도 많다. 이는 속도 측면에서도 빨라지지만, 혹시나 발생할지 모르는 오류를 최소화하기 위한 노력이기도 하다. 이 때문에 윈도의 GUI 환경 자체를 낭비라고 생각하는 경우도 있다. 실제 서비스가 이루어지는 서버는 원격으로 접속, 작업만 가능하면 될 뿐 상대적으로 콘솔 모드보다 많은 시스템 자원을 요구하는 GUI 환경은 사용되지 않는 경우가 많다. 때때로 리눅스 환경에서도 편의를 위해 X윈도 위에서 개발하는 경우도 있지만, 실제 서비스할 때는 콤팩트하게 설치된 서버에서 게임 서버만 동작할 수 있는 최소한의 환경을 만드는 경우가 많다. 그러한 면에서 볼 때 시스템의 아주 미세한 부분까지 오픈돼 있어 개발자가 직접 튜닝이 가능한 리눅스 시스템은 성능과 안정성 면에서 많은 장점이 있다.

 이제 단점 부분을 살펴보자. 사용상의 까다로움과 같은 불편함은 단점이 될 수도 있다. 그러나 이부분은 적응만 잘하면 오히려 편하다고 생각하는 경우도 있기 때문에 논의 대상이 아니다라고 본다. 하지만 개발하면서 느낄 수 있는 리눅스 및 유닉스 시스템의 결정적인 문제점은 바로 네트워크 게임 서버로서의 핵심 부분인 소켓(Socket) 처리 부분에 있다. 리눅스에서 서버 개발을 하려면 가장 기본적인 방식이 셀렉트(select), 폴(poll)을 이용한 폴링(polling) 방식이라 할 수 있다. 이 방식은 BSD 소켓에서 다수의 접속을 처리하는 방법으로써 가장 보편적이고 쉬운 방식이기 때문에 지금까지도 많이 사용되고 있다. 그림1 참조, http://chonga.pe.kr 참고

 하지만 폴링 방식은 그 설계 특성상, 하나의 데이터 수신 여부를 검사하기 위해 전체 소켓 디스크립터를 처음부터 끝까지 검사해야 하는 방식을 취하고 있다. 예전처럼 하나의 게임에 수십명에서 많아 봐야 백여명이 존재하던 머드 게임들에서는 큰 문제가 없었다고 얘기할 수 있다. 하지만 점차 게임의 규모가 커지고, 지금처럼 최소한 몇 백명에서 많게는 수천명 이상을 처리해야 하는 온라인게임 서버로 사용하기에는 필요없는 성능 낭비가 두드러지게 발생하게 된다. 마치 전화번호부에서 특정 사람을 찾기 위해 가, 나, 다로 정렬된 간편한 인덱스(Index)를 사용하는 것이 아니라 처음부터 끝까지 훑어야 한다는 문제점이 있는 것과 같은 이치다. 그 숫자가 몇십명 정도이면 큰 문제가 되지 않지만, 수백명, 수천명 이상으로 늘어나기 시작할 때는 성능상의 쓸데없는 낭비가 심해지게 된다.

 웹 서버, 혹은 DB 서버처럼 서로 간의 클라이언트끼리의 상호작용이 거의 없다면 클라이언트당 하나의 스레드(Thread)를 만들거나, 혹은 스레드 풀을 충분히 활용한다 던지하는 방법으로 충분히 해소가 가능하다. 하지만 클라이언트들끼리의 상호작용이 극단적으로 많은 온라인게임에서는 위의 방법은 오히려 좋은 방법이 되지 못할 수 있다. 그래서 많은 개발자들은 위에서 언급한 문제들을 해결하기 위해 실제로 제작을 할 때는 접속을 받는 접속단을 여러 개의 프로세스로 병렬 처리하고, 중간에 게이트웨이(Gateway) 등을 거쳐서 실제 게임 프로세싱(Processing) 서버를 따로 두는 방식을 사용하기도 했다. 하지만, 그런 방법은 제작도 복잡하고 설치 및 유지 보수 역시 손이 많이 가기 때문에 최근에는 그렇게 사용하는 예가 줄어들고 있다.

 다음은 스레드 관련 내용이다. 원래부터 유닉스 자체는 싱글 스레드(싱글 프로세스)를 염두에 두고 만들어진 운용체계이기 때문에 멀티 스레딩의 지원이 불충분한 경우가 많다. 실제로 리눅스의 경우에는 스레드의 기본 개념인 가벼운 과정(lightweight process)과는 달리 실질적으로는 하나의 독립된 프로세스에 가까울 정도로 무겁다. 멀티 스레딩으로 사용할 때 실제로 생성된 스레드 외에도 각각의 스레드들을 관리해주는 별도의 스레드 역시 발생하기 때문에 OS에 주는 부담도 클 수 있다. 하지만, 어디까지나 개념적인 내용이고, 실제로 리눅스에서 멀티 스레딩 서버를 개발하고 운용해 오면서 그다지 큰 문제는 겪어 본 적이 없기 때문에 치명적인 단점이라고는 할 수 없을 것 같다.

 ◇윈도 플랫폼=이제 윈도 서버 플랫폼에 대해 살펴보자. 유닉스 환경에서만 오랫동안 일을 하다가 우연한 기회에 윈도 서버로 개발 플랫폼을 바꾸게 됐고, 그곳에서 서버를 개발하면서 IOCP를 이용한 환경에서 작업한 경험이 있다. 이러한 개발환경 전환 과정에서 느꼈던 장단점은 다음과 같다.

 단점으로는 역시 리눅스나 FreeBSD에서 OS 자체를 미세하게 조절할 수 있었던 것과는 달리 실제로 게임 서버만을 동작시키기에는 불필요한 다른 기능들과 자원들이 소모된다는 점이다. 여러 가지 기능들이 동작하고 다른 서비스들이 많이 있다는 것은 그만큼 사용하기가 편리할 수는 있겠다. 하지만, 시스템상의 오류가 발생할 수 있는 소지가 많고, 외부에서의 악의적인 공격들에 대해서 그만큼 공격당할 구석이 많아진다. 그렇지만, 최근에 와서는 MS의 지속적인 보안 강화 노력 등과 군살 줄이기 노력 등으로 인해 크게 염려할 수준은 되지 않는 것 같다. 실제로 윈도서버 2003 같은 경우에는 상당히 콤팩트 하게 구성되어 있다는 개인적인 생각이다. 그 외에도 상대적으로 비용이 비싸다는 단점도 있다. 중소 개발사의 경우는 결코 무시하지 못할 부담으로 작용하기도 한다.

 이제 윈도에서 개발을 할 경우의 장점을 살펴보자. 무엇보다 사용상의 편의점이다. 비주얼 스튜디오로 대변되는 강력한 개발 도구부터, 수많은 벤더에서 제공해주는 다양한 유틸리티들과 편리한 사용 환경 덕분에 처음 개발을 하게 되더라도 그만큼 빨리 익숙해지며, 정보를 얻기도 비교적 쉽기 때문에 개발하는데 있어서 그만큼 많은 이득을 가지고 출발한다고 생각한다.

 다음으로는 가장 중요한 게임 서버로서 윈도서버가 제공해주는 강력한 기능인 IOCP를 꼽을 수 있다. 물론 IOCP 자체는 여러가지 용도로 사용될 수 있지만, 네트워크 처리 부분에 사용하게 될 때 폴링방식이 아닌 이벤트 드리븐(Events Driven) 방식으로 클라이언트들에서 오는 데이터를 커다란 성능 손실없이 처리해주는 것 역시 기존 BSD 소켓의 select, poll 등에 비교해 볼 때 확실한 장점으로 꼽을 수 있다. 그리고 윈도NT 기반이 멀티 스레딩 환경을 염두에 두고 개발된 환경이라 스레딩에 대한 지원이 잘 되어 있고, 그 기반에서 작동되는 IOCP는 다중 CPU 환경에서 머신의 능력을 최대한 이끌어낼 수 있는 설계라고 생각한다. 때문에 최근에는 수많은 게임 개발사들에서 윈도 플랫폼에서 개발을 하고 있으며, 많은 상용 게임들 역시 그 기반에서 작성되고 운용되고 있는 실정이다. 물론 몇가지 변수가 있고 게임에 따라 달라지긴 하겠지만, 실제로 상용화됐고 성공한 많은 게임들이 적절한 스레딩 처리와 IOCP의 장점을 십분 활용하고 최근에 나오는 강력한 다중 CPU 머신을 활용하는 경우가 많다. 기존에 커다란 필드를 여러 개의 분산 서버로 나누어 처리했던 것을 하나의 머신에서 하나의 서버 인스턴스(Instance)로 처리하고 있는 것이다.

 ◇ 최신 동향에 기울여야=앞서 얘기했던 두 플랫폼에서 서버 개발을 할 때 존재하는 장단점들을 해결하기 위한 쉼 없는 노력을 위하여 지금도 개발자들은 밤을 지새우고 있을 것이다. 리눅스에서 RTS(Real Time Signal), /dev/epoll 방식 등이 그 예다. 아직까지는 실제로 서비스되는 게임들 중에 위 방식으로 제작되었다는 구체적인 사례는 알려져 있지 않다. 그러나 사용 사례들이 많아지고 개발 노하우 공유가 크게 이루어진다면 이제 대형 온라인 게임 서버로서 리눅스 플랫폼도 충분히 주목받을 수 있는 기회가 올 것이라고 생각한다. 또한 윈도 플랫폼에서도 서드 파티에 대한 좀더 적극적인 지원이 이루어진다면 세계적인 온라인게임 서버기술력을 보유한 우리로서는 다양성에 고민하지 않을 수 없을 것이다.

 peostar@gravity.co.kr

 

<필자 약력>김상근

◇현대전자 소프트웨어연구소 책임연구원

◇고려대학교 전기전자공학부(인공지능전공) 박사

◇아라아이디시 기술이사

◇이노리소프트 대표이사

◇그라비티 기술이사 및 연구소장

○ 신문게재일자 : 2004/08/17
○ 입력시간 : 2004/08/16 14:54:46

File attachments: 
첨부파일 크기
PDF icon 2001-12.pdf2.01 MB
ddoman의 이미지

Quote:
 ◇ 최신 동향에 기울여야=앞서 얘기했던 두 플랫폼에서 서버 개발을 할 때 존재하는 장단점들을 해결하기 위한 쉼 없는 노력을 위하여 지금도 개발자들은 밤을 지새우고 있을 것이다. 리눅스에서 RTS(Real Time Signal), /dev/epoll 방식 등이 그 예다. 아직까지는 실제로 서비스되는 게임들 중에 위 방식으로 제작되었다는 구체적인 사례는 알려져 있지 않다. 그러나 사용 사례들이 많아지고 개발 노하우 공유가 크게 이루어진다면 이제 대형 온라인 게임 서버로서 리눅스 플랫폼도 충분히 주목받을 수 있는 기회가 올 것이라고 생각한다. 또한 윈도 플랫폼에서도 서드 파티에 대한 좀더 적극적인 지원이 이루어진다면 세계적인 온라인게임 서버기술력을 보유한 우리로서는 다양성에 고민하지 않을 수 없을 것이다.

epoll도 그렇고 nptl도 그렇고..리눅스의 단점으로 제시한 점에 대한 대책들이 나온지 좀(?) 됐지만..이분은

Quote:
아직까지는 실제로 서비스되는 게임들 중에 위 방식으로 제작되었다는 구체적인 사례는 알려져 있지 않다

라는 써놓으셨네요..흐음..

Necromancer의 이미지

epoll 나온지 얼마 안됐지요.

joinc에 epoll 사용 강좌가 올라왔길레 거기 답글들을 보니

페도라 2에서도 컴팔 안되서 무슨라이브러리 구해다 컴팔하니 하는 답글이
죽 달렸던데요.

이정도라면 리눅스 매니아층이 아닌 다른 사람들에게는 거의 안 알려져 있을겁니다.
특히 리눅스 자체 관심 없이 리눅스로 각종 서비스를 하는 사람들에게는 말이죠.

Written By the Black Knight of Destruction

cjh의 이미지

많은 게임 서버들이 윈도 플랫폼인건 확실한 것 같더군요. 리눅스로 돌아가는(또는 유닉스) 온라인 게임이 어떤게 있는지 알고 싶습니다.

고급 다중 처리 인터페이스는 *BSD의 kqueue가 가장 쓸만한 텐데, 이건 epoll처럼 도입하기 어렵지도 않고(이미 최근 버전의 *BSD에는 모두 내장) 소켓 말고 다른 시스템 이벤트(장치, 파일시스템 등)도 다룰 수 있죠. 이런 걸 활용하면 가장 좋겠지만 개발자들이 얼마나 관심들이 있을지...

--
익스펙토 페트로눔

seoleda의 이미지

Quote:

웹 서버, 혹은 DB 서버처럼 서로 간의 클라이언트끼리의 상호작용이 거의 없다면 클라이언트당 하나의 스레드(Thread)를 만들거나, 혹은 스레드 풀을 충분히 활용한다 던지하는 방법으로 충분히 해소가 가능하다. 하지만 클라이언트들끼리의 상호작용이 극단적으로 많은 온라인게임에서는 위의 방법은 오히려 좋은 방법이 되지 못할 수 있다.

클라이언트당 하나의 스레드를 만드는 방식이 왜 클라이언트 끼리의 상호작용에 방해가 될까요?

제 생각엔, 기본적으로 쓰레드간에는 변수가 공유되므로, 문제될것이 없을거 같은데요. ^^

drinkme의 이미지

쓰레드간의 data공유는 '상호배제' 원칙하에...
이런거 처리하다 보면, 코드도 복잡해지지만, 성능도 떨어지게 되죠.

버려진의 이미지

Quote:
스레드의 기본 개념인 가벼운 과정(lightweight process)

전 이게 재밌네요 ^^;

보쌈류의 단어인듯...

Zeroidle의 이미지

https://www.sephiroth.co.kr

여기 3D MMORPG인 Sephiroth 라는 게임은

솔라리스 상에서 작동한다고 알고있는데요..

ftfuture의 이미지

데드락이라든지 기타 문제를 방지하기 위해 뮤텍스 락을 걸어주어야 하기 때문이 아닐까요?

seoleda wrote:
Quote:

웹 서버, 혹은 DB 서버처럼 서로 간의 클라이언트끼리의 상호작용이 거의 없다면 클라이언트당 하나의 스레드(Thread)를 만들거나, 혹은 스레드 풀을 충분히 활용한다 던지하는 방법으로 충분히 해소가 가능하다. 하지만 클라이언트들끼리의 상호작용이 극단적으로 많은 온라인게임에서는 위의 방법은 오히려 좋은 방법이 되지 못할 수 있다.

클라이언트당 하나의 스레드를 만드는 방식이 왜 클라이언트 끼리의 상호작용에 방해가 될까요?

제 생각엔, 기본적으로 쓰레드간에는 변수가 공유되므로, 문제될것이 없을거 같은데요. ^^

seoleda의 이미지

Quote:

데드락이라든지 기타 문제를 방지하기 위해 뮤텍스 락을 걸어주어야 하기 때문이 아닐까요?

그러한 문제라면 windows에서의 IOCP도 자유로울 수 없을거 같습니다.

gogo의 이미지

국내 5대 게임업체의 기술이사님은 운영체제 시간엔 졸으신듯..ㅋㅋㅋ

찾아보면 리눅스나 unix에서 서비스 하는 회사들 좀 있습니다. 윈도우 보다는

훨신 적지만요.. 개발사에서 우리 서버는 무슨 플랫폼에서 돌아간다고

광고하진 않잖아요... 그냥 묵시적으로 알고 있을뿐이죠..

dudungsil의 이미지

cjh wrote:
많은 게임 서버들이 윈도 플랫폼인건 확실한 것 같더군요. 리눅스로 돌아가는(또는 유닉스) 온라인 게임이 어떤게 있는지 알고 싶습니다.

일단 리눅스 서버로 가장 유명한 게임은 Mythic사의 Dark age of camelot이 있겠군요. 한국에서는 죽썼지만 북미/유럽에서는 엄청난 (이 표현이 그리 틀리지 않을겁니다) 성공을 했습니다. 리눅스+mySQL 조합이죠. 2001년 10월인가에 패키지 판매를 시작했으니 시기적으로 볼때 epoll등의 기술이 적용되기는 힘들었을 것 같습니다.

한국의 덩치있는 게임 개발사중에는 넥슨이 솔라리스 환경에서 서버를 개발할겁니다. 그 이외에 특별히 알려진 사실은 없네요.

게임서버에 윈도우서버가 사용되는건 꼭 한국만 그런건 아닌것 같습니다. 배틀넷도 그렇고 애쉬론즈콜(MS와 관계를 맺기 전부터)도 그렇고 대부분의 유명한 게임들은 모두 윈도우서버네요.

ps. 글을 쓰고 나서 생각났는데 아마 파판XI은 리눅스 서버일겁니다. 이건 정확치 않네요. 글을 오래전에 읽었던거 같습니다.

산넘어 산

dudungsil의 이미지

gogo wrote:
...

개발사에서 우리 서버는 무슨 플랫폼에서 돌아간다고 광고하진 않잖아요... 그냥 묵시적으로 알고 있을뿐이죠..

상장한 회사의 경우에는 광고를 해야합니다. 광고라기 보다는 IR 차원에서 사용 기술을 홍보해야하죠. 그래서 윈도우 서버가 더 많이 알려진 것일수도 있습니다. 상장사가 모두 윈도우서버니 그 광고효과를 무시할수 없고, 공부하는 학생에게도 많은 영향을 미치겠죠.

산넘어 산

bt의 이미지

DAoC (Dark Age of Camelot)이 리눅스 기반의 게임이라고 들었습니다.

서지훈의 이미지

cjh wrote:
많은 게임 서버들이 윈도 플랫폼인건 확실한 것 같더군요. 리눅스로 돌아가는(또는 유닉스) 온라인 게임이 어떤게 있는지 알고 싶습니다.

고급 다중 처리 인터페이스는 *BSD의 kqueue가 가장 쓸만한 텐데, 이건 epoll처럼 도입하기 어렵지도 않고(이미 최근 버전의 *BSD에는 모두 내장) 소켓 말고 다른 시스템 이벤트(장치, 파일시스템 등)도 다룰 수 있죠. 이런 걸 활용하면 가장 좋겠지만 개발자들이 얼마나 관심들이 있을지...


http://www.metin2.co.kr
여기사 메틴2라는 온라인 게임 사이트 인데...
원래는 프비로 돌리다 얼마전에 수세+MySQL+AMD Opteron 이렇게 삼위 일체로 돌리고 있습니다(DB Server).
http://www.metin2.co.kr/01_news/news_03_view.htm?table=press&id=69
근데 여기서 프비를 쓸데보다 리눅스를 사용할 때...
2배 정도의 성능 향상이 있었다고 한는데...
그때도 옵테론으로 돌렸을까 쉽은 생각이 문득문득 드는군요.

그래도 지금도 웹은 아직 프비 5.2.1에서 돌리고 있는듯 합니다.
근데... 제가 보기엔 웹쪽으로는 프비는 좀 아닌듯 한데...-_-ㅋ

<어떠한 역경에도 굴하지 않는 '하양 지훈'>

#include <com.h> <C2H5OH.h> <woman.h>
do { if (com) hacking(); if (money) drinking(); if (women) loving(); } while (1);

gogo의 이미지

dudungsil wrote:
gogo wrote:
...

개발사에서 우리 서버는 무슨 플랫폼에서 돌아간다고 광고하진 않잖아요... 그냥 묵시적으로 알고 있을뿐이죠..

상장한 회사의 경우에는 광고를 해야합니다. 광고라기 보다는 IR 차원에서 사용 기술을 홍보해야하죠. 그래서 윈도우 서버가 더 많이 알려진 것일수도 있습니다. 상장사가 모두 윈도우서버니 그 광고효과를 무시할수 없고, 공부하는 학생에게도 많은 영향을 미치겠죠.

제가 못찾는건지 상장사들 IR 자료를 아무리 봐도 기술같은것도 안나오지만

OS를 멀쓰는지에 대해서도 잘 안나오네요..링크 같은거라도 있으심 좀 알려

주심 도움이 되겠네요..

그리고 파이날 판타지는 솔라리스x86 기반으로

제작되었습니다. 그 무식하다는 pc 서버 1250대로 구성되었다죠..

댓글 첨부 파일: 
첨부파일 크기
PDF icon 0바이트
fghj1의 이미지

본문의 글은 2004년에 작성된 글인 것같습니다. 본문의 내용은 언뜻, 쓰레드 활용(?)에 있어서 리눅스보다 윈도우가 보다 효율적이라고 얘기하고 있는 것같습니다. 근데 윈도우의 쓰레드와 리눅스의 쓰레드에 대한 차이점을 검색하다가 다음과 같은 링크의 글을 보게 되었습니다.

http://www.ibm.com/developerworks/kr/library/l-rt7/index.html

이 글은 2002년에 작성된 글로 왠지 번역이 좀 매끄럽지 못하지만 대략, 그래프만 봐도 리눅스가 쓰레드 관리에 있어 윈도우보다 효율적이라고 얘기하는 것같습니다. 하지만, 여기엔 제가 이해하지 못한 어떤 중요한 차이가 있지 않나 싶습니다. 아직 내공이 부족해 그것이 무엇인지 잘 모르겠습니다. 여기 고수님들이 혹시 본문과 위 링크의 글을 이해하는데 간과해서는 안될 지식이 있다면 귀담아 듣고자 벌써 4~5년이 지난 글임에도 불구하고 댓글을 남겨 봅니다.

그리고 참고로 들은 얘기인데 엠게임에서는 대부분의 프로젝트(게임)를 윈도우가 아닌 리눅스를 사용하여 진행한다고 합니다.(또는 진행할 계획이라고 합니다.)

bookworm의 이미지

윈도우냐 리눅스냐는 OS 상의 어떤 이점 보다는 그냥 개발인력 수급의 문제가 아닐까 싶습니다.

특히 윈도우에서 서버를 개발하면 한명으로 클라/서버 다 시킬 수 있죠. (전 이게 정답이라고 봅니다.)

--

B/o/o/k/w/o/r/m/

B/o/o/k/w/o/r/m/

chunsj의 이미지

저도 +1, 그리고 베껴서 사용할 코드도 많고... (상대적으로 싼 인력을 굴릴 수 있죠, 그리고
전체 비용에서 인력이 차지하는 비용이 더 작으니 인력 잘 못 뽑았다는 비난을 들을 가능성도
줄고...)

inhosens의 이미지

초기 (커널 2.2 대) 리눅스 쓰레드는 프로세스로 쓰레드 흉내를 내는 형식이었습니다.
원글을 쓰신분이 매우 안정성을 추구하신 나머지 오래된 커널을 사용하시려고 고려중이셨나보죠.
아니면 리눅스에서 윈도우즈 서버로 아주 오래전에 넘어오셨던지요.

Fe.head의 이미지

인력 문제, 개발툴이 가장 문제가 아닐까 하는 생각을 하네요.

vim,(아주많이 쓰고 있음) kdevelop(잠시써봤음) 등을 써봤지만.. 비주얼 C++의 편리함을을 따라가기에는 역부족이 아닌가 싶습니다.
-----------------------
과거를 알고 싶거든 오늘의 네 모습을 보아라. 그것이 과거의 너니라.
그리고 내일을 알고 싶으냐?
그러면 오늘의 너를 보아라. 그것이 바로 미래의 너니라.

고작 블로킹 하나, 고작 25점 중에 1점, 고작 부활동
"만약 그 순간이 온다면 그때가 네가 배구에 빠지는 순간이야"

itlognext의 이미지

리눅스의 위대함을 다시한번 실감하게 되네요~!

queryman의 이미지

네오플의 신야구 라는 게임이 리눅스 기반입니다...

-------------------------------------------------------------------------------------------
생각은 지나가던 개새끼도 하지.. 실천하는건?? 나도 할수있지...
http://www.mrdics.com


-------------------------------------------------------------------------------------------
이놈의 IT 생활... 실증나고 짜증나고...
근데 왜 맨날 it관련 소식만 보고 ;;; 님휘

nineye의 이미지

저도 iocp와 epoll중, 어떤 것이 성능이 좋을까 생각하다가
제 블로그에 글을 하나 썼는데요, 이 글에 대해 평가 좀 부탁합니다.
제가 잘못알고 있는 부분은 지적 부탁드립니다...

http://nineye.net/blog/archives/692

_________________________________________________________

nineye's blog

blee의 이미지

리눅스를 더 좋아 하긴 하는데, 솔직히 IOCP 기술은 상당한 매력이 있었습니다. 서버의 부하를 결정하는 두가지 요소가 스케쥴과 메모리 이동이라고 본다면, IOCP 가 솔직히 소켓통신을 위해서는 최고 일것 같은데? 제가 아는 지식이 짧다 보니 그렇게 생각 할 수도 있습니다.
리눅스에서 RTS(Real Time Signal), /dev/epoll 방식 IOCP 를 대체 할만 한가요?

serialx의 이미지

libevent 2.0 벤치마크 결과가 zero copy 의 위력을 알려주고 있습니다:

http://www.provos.org/index.php?/archives/61-Small-Libevent-2.0-Performance-Test.html

* 1.4.10:
Requests per second: 1450.79 [#/sec] (mean)
* 2.0:
Requests per second: 1961.99 [#/sec] (mean)
* 2.0 (evbuffer_add_reference):
Requests per second: 3979.31 [#/sec] (mean)

메모리 복사를 최소화한 evbuffer_add_reference 가 약 35%의 성능 향상을 보인다고 합니다. (epoll + splice 를 사용한 zero copy)

리눅스에서의 zero copy 는 IOCP 처럼 네트워크/파일 I/O 에 국한된 시스템이 아니라 시스템 내부에 박혀 다양하게 사용 가능한 상태였습니다. splice/sendfile 형태로 말이지요. 그리고 유닉스 철학에 맞게 epoll은 socket event notification만을 담당하는 녀석이었고요. 이 둘을 합치면 IOCP 화 비슷한 효과가 나겠지요.

이와같은 내용은 작년에도 나왔던 얘기입니다:

http://kldp.org/node/96355#comment-452240

누군가가 IOCP/epoll+splice 벤치마크 해주셨으면 하는데.. ㅎㅎ