초당 10000 개의 TCP 연결을 처리하는 시스템을 설계하고 있는데 어떤 문제가 발생합니까?

18

CentOS를 실행하는 비교적 새로운 8 코어 상자가 있습니다. TCP를 사용하는 통계 서버를 개발하고 싶습니다. 매우 간단합니다. TCP 연결을 수락하고 카운터를 늘리고 연결을 닫습니다. catch는 적어도 초당 10k 요청을 수행해야한다는 것입니다. CPU / 메모리가 문제가되지 않을 것이라고 생각하지만, 이런 종류의 볼륨을 허용하기 위해 서버에서 구성해야하는 인위적인 제한 (반 개방 연결과 같은)에 더 관심이 있습니다. 이것이 가능합니까? 어떤 설정을 알고 있어야합니까? NIC가 처리 할 수 없습니까?

1

들어오는 모든 연결을위한 산란 스레드, 그것은 성능을 죽일거야하지 있는지 확인

1

최종 결과를 여기에서보고 +1 :)

— agsamek

17

이것은 일반적으로 c10k 문제 로 알려져 있습니다. 이 페이지에는 발생할 수있는 문제에 대한 많은 정보가 있습니다.

— 그렉 휴길
소스

그래, 좋은 링크!

— sybreon

1

c10k 페이지에 언급 된 것보다 더 많은 / 다른 문제가 발생할 것으로 기대합니다. 초당 10k 연결을 설정하고 닫는 것은 10k 열린 연결을 갖는 것과 다릅니다. TIME_WAIT 상태를 유지하는 연결은 하나이며 수신 소켓의 백 로그 한계에 도달하면 다른 연결 일 수 있습니다. 그리고 유스 케이스가 일반적인 10k 개방 연결 케이스보다 커널 코드에서 많은 프로파일 링 / 최적화를받지 못했다면 놀라지 않을 것입니다.

— cmeerw

2

당신은 그것을 할 수 있어야한다 [아마도 나쁜 생각이다].

에 수지 의 appserv 내가 쿼드 코어 2.6GHz의 제온에 ~ 5K 필수 / 초를 얻을 수 있습니다. 요청은 mysql에서 1 행을 읽고 매우 작은 XML 응답을 보내는 간단한 서블릿을 호출합니다.

시험은 끝났다

ab -n 10000 -c 16 http://some/url/

시험 결과:

Concurrency Level:      16
Time taken for tests:   1.904 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      3190000 bytes
HTML transferred:       1850000 bytes
Requests per second:    5252.96 [#/sec] (mean)
Time per request:       3.046 [ms] (mean)
Time per request:       0.190 [ms] (mean, across all concurrent requests)
Transfer rate:          1636.42 [Kbytes/sec] received

하지만 각 요청마다 새로운 스레드를 생성하지 않고 간단한 c 프로그램을 사용하는 것이 훨씬 나을 것이라고 생각합니다. Greg Hewgill의 링크는 이에 대한 좋은 아이디어를 제공해야합니다.

장기간의 테스트 중에도 연결성에 대한 문제는 없습니다. 대역폭이 병목 현상이 아님에도 불구하고 기가비트 이더넷을 통해 연결된 두 개의 리눅스 박스 사이에서 테스트가 실행됩니다.

— pQd
소스

OP와 같은 모든 응답 후 연결이 닫혀 있습니까? ab가 Connection : close 헤더를 전송 중입니까?

— Nate

1

@Nate http http-모든 단일 HTTP 요청에 대한 단일 연결입니다.

— pQd

1

Apache를로드 테스트하는 동안 적중 한 Linux 커널 제한에 관심이있을 수 있습니다 . 필자의 경우 커널은 유용한 오류 메시지를 생성하여 조언을 구하는 것이 프로그램을 작성하고 한계에 도달하는 경우 커널 로그에주의를 기울이십시오.

— 벤 윌리엄스
소스

0

가능한 경우 TCP 대신 UDP를 사용합니다. 더 가벼워 지므로 확장 성이 좋아야합니다.

— Zimmy-DUB-Zongy-Zong-DUBBY
소스

나는 동의한다. UDP는 훨씬 더 가벼운 것

— fpmurphy

1

UDP에는 발신자 및 배달 확인과 같은 단점이 있으므로 프로덕션 환경에서 UDP를 사용하기 전에 고려해야합니다.

— SaveTheRbtz

0

당신의 nic은 그것을 처리 할 수 있어야하지만, 초당 10k 개의 새로운 TCP 연결을 갖는 디자인에 의문을 가지고 있습니다. 연결을 빠르게 생성 / 파괴하는 경우 a) 연결을 더 길게 유지하거나 b) 대신 UDP를 사용해야합니다.

때때로 쿼리를 수행해야하는 1M 개의 클라이언트가 있지만로드가 초당 10k에 도달하는 경우 UDP가 더 나은 선택 일 수 있습니다.

1 초마다 쿼리를 수행해야하는 10k 개의 클라이언트 만있는 경우 기존 연결을 열어두고 재사용 할 수 있습니다. 이것은 OS에 훨씬 더 친절하고 매번 새로운 핸드 셰이크가 필요하지 않기 때문에 대기 시간이 훨씬 줄어 듭니다.

초당 10k 요청이있는 경우 어쨌든 프론트 엔드로드 밸런서가 있다고 생각하므로 테스트해야합니다.

(NB : 이것이 스택 오버플로에 속해 있다고 생각합니다)

— MarkR
소스