이럴때 TCP 커넥션을 유지해야 할까요?
글쓴이: cleol / 작성시간: 목, 2004/01/22 - 10:50오후
서버가 한 대 있고 2000 ~ 3000 개 정도의 클라이언트가 있습니다. 클라이언트는 매 5초 또는 10초 마다 간단한 메세지(50 바이트 이하)를 서버에 보내고 응답(50 바이트 이하)을 받습니다. 연결은 TCP 를 사용합니다. 이럴때 클라이언트와 서버가 계속 연결을 유지하고 있는게 서버에 부담이 적을까요? 아니면 메세지를 보낼 때마다 접속했다가 바로 연결을 끊는 것이 부담이 적을까요? 물론 실제로 테스트를 해보는 것이 가장 확실하겠지만 그래도 다른 분들의 조언을 듣고 싶습니다.
Forums:
당연히 연결을 유지하는 편이 서버에 부하가 덜 걸리죠.연결 한번 할때
당연히 연결을 유지하는 편이 서버에 부하가 덜 걸리죠.
연결 한번 할때마다 내부적인 핸드쉐이킹과정도 있고 나름데로 메모리 할당등 절차가 필요할텐데 이런 부분이 없어지니까요.
수천개의 접속이라면 select()를 쓰진 않을테고 그렇다면 접속 유지하는 만큼 메모리는 조금 차지하겠지만 접속을 많이 유지 한다고 더 부하가 걸리지는 않습니다.
그렇지만 직접 테스트를 한번 해보는걸 권해 보고 싶네요.
한번은 직접 해봐야지 그냥 남이 말만 들으면 언제까지나 이게 정말 맞는건가 얼마나 차이가 나는건가 하는 의문이 계속 남게 될겁니다.
답변 감사합니다.
답변 감사합니다 :o 그런데 "수천개의 접속이라면 select()를 쓰진 않을테고" 라는 말씀을 잘 모르겠습니다. 저는 당연히 select()를 사용하고 메세지를 읽을 때마다 쓰레드 풀에서 쓰레드를 얻어서 처리하는 방식으로 구현하려고 생각했습니다. 제가 말씀드린 상황에서 select() 를 사용하지 않는 쪽이 좋은가요?
설계시에 가장 주의할 것이 쓸 데 없는 일을 최대한 줄이는 것입니다.
설계시에 가장 주의할 것이 쓸 데 없는 일을 최대한 줄이는 것입니다.
이 쓸 데 없는 일이라는 것이 환경에 따라 어디에서는 좋은 것이 되고, 어디에서는 나쁜것이 되는것이라 정확히 알아내는 데는 수많은 시행착오가 필요합니다.
하고자하는 일은 클라이언트로부터 몇초단위로 짧은 데이터를 계속 받는 환경을 견디는 설계입니다.
이것을 위해 영구접속 방식을 사용할 것이냐와 일회접속 방식을 사용할 것이냐를 선택하는 것이군요.
이것에 맞물려 있는 중요한 설계상의 요점은,
요 정도의 생각할 요점이 있습니다.
제 생각에는 평균응답지연정도이 그다지 오래지 않을 것이라 생각되므로, 접속을 매번 끊는 것도 좋고, 접속이 무한정 늘지 않을 것이라 생각되므로 영구접속도 좋습니다.
매번 끊는 경우 접속당 전담하는 작업개체로 만들고 (동시 요청 패킷의 갯수) * 2 배수 만큼의 pre-forked process 혹은 pre-created thread 방식으로 만드는 것이 좋겠습니다.
50 byte를 보내는데 들어가는 접속 비용이 훨씬 많이 들어가는 모델이긴 합니다만, 접속 유지 비용또한 만만치 않습니다.
접속 유지비용은 접속이 끊겼는지 확인하는 것 혹은 동시 open descriptor 수 등입니다.
접속을 계속 유지하는 경우라면, 5 개정도로 pre-forked 로 한 다음 select 등으로 다중화하는 것도 좋을 것입니다.
[/]이 경우 접속이 조용히 끊긴 경우를 대비하여 keep alive를 사용하여야 합니다.
---
http://coolengineer.com
Re: 답변 감사합니다.
Realtime Singnal이나 Event Poll같은걸 사용할꺼라 생각했거든요.
epoll의 경우는 아직 사용해보질 못했지만 리얼타임시그널보다 더 효율적이라고 하더군요.
리얼타임시그널 방식은 재작년부터 썼는데 당시 느끼던 select의 문제들이 - 최대접속수와 동시접속이 늘어날때마다 걸리는 패킷처리 시간 - 다 해결되더군요.
당시 테스트 했을때 수천개의 동시 접속이 있는 상황에서 초당 만5천개가량의 수십바이트 짜리 패킷을 처리했습니다.
select()라는것이 접속이 수백개만 넘어도 부하가 꽤 걸리더라고요.
댓글 달기