| [ CnUnix ] in KIDS 글 쓴 이(By): swhan (차카게산다) 날 짜 (Date): 2003년 8월 1일 금요일 오후 02시 07분 12초 제 목(Title): Re: Unix Domain Socket 다른 조건은 다 빼고, unix system 내부에서 1:N간 (또는 N:N간) IPC에 가장 빠른 방법은.. 우선 빠르다는 단어의 정의부터 해야하겠습니다. :p (throughput인지 delay인지, latency인지..) 대충 생략하고. 1:1000이라면(실제 process가 1000개라면!) POSIX signal+ shared memory를 권하고 싶습니다. shared memory에는 buffer pool을 갖고 있어야 합니다 또한 shared memory에는 process list가 필요합니다. 모든 process는 signal wait상태이고 하나의 process가 이벤트를 받으면 buffer pool에서 buffer를 할당받습니다. 기록하고, process list에서 이 이벤트를 처리할 프로세스를 찾습니다. 그리고 POSIX signal에 buffer id를 넣어서 보내줍니다. signal을 받은 process는 wake되면서 buffer id를 받아 바로 처리하고 다시 sleep (thread라면 이 방법은 안됩니다. signal을 thread별로 구분해서 보내줄 방법이 없습니다.) --- 위 얘기와 상관 없이, 1000개의 connection에 대해서는, 저라면 , connection pool을 갖는 단일 process를 만들고 이 process에 thread pool을 유지하겠습니다. 그리고 이 process에 event를 전달할 message queue가 필요합니다. (POSIX signal은 안되고, POSIX M.Q쉽고 Shared memory는 memory copy를 줄일 수 있겠지요.) thread중 깨어난 아무나 event를 잡아서 송수신 작업만 수행하면 되겠습니다. 한 client에 대해 2개의 thread가 동시에 처리하는 일을 방지하기 위한 mutex도 client수만큼 추가해야겠구요. 결국 내부 IPC는 message queue또는 shared memory로 귀결되는군요. ------ 내부 상태 관리를 지속적으로 해야 하는 client가 아니라 메신저 역할의 서버라면 process를 client만큼 띄우는 것은 memory overhead와 context switching의 overhead를 생각해서 피하는게 좋을 것 같습니다. 또한 단일 thread(of process)에서 1000개의 연결을 모두 전담하여 처리하는 것은 async I/O나 non-block I/O에 과도하게 의존하지 않으면 실시간 처리가 상당히 힘들 것이기 때문에 역시 피하는게 좋겠지요. 처리 루틴 자체가 너무 복잡해지니까요. 또 async I/O는 대부분 OS에서 별도 thread를 생성해서 처리하기 때문에 부하가 걸리는 시스템에서는 피하는게 좋을꺼라는게 개인적인 생각입니다.(실험 데이터나 다른 근거는 없습니다. 그냥 추측입니다. :) ) |