Windows 네트워크 프로그래밍에 대한 정보를 찾고 있습니다. 주로 1000 개의 연결에 대처할 수있는 단일 실행 파일을 얻는 방법.Windows 소켓 소켓 성능
우리는 유닉스에서 select() FD_ISSET 등을 사용하며 매우 빠르게 작동합니다. Windows에서 이러한 API는 매우 열악합니다. FD_SET은 훨씬 느리지 만,이 문제를 해결할 때조차도 Windows는 HPUX보다 훨씬 느립니다.
나는 많은 CPU/시간을 필요로하지 않는 select() 호출 대신 사용할 수있는 win32 API 호출을 찾고 있습니다. 현재 우리는 send()와 recv()에서 유닉스가 보낸 시간 인 select()에 시간과 CPU의 50 %를 소비합니다.
감사 닐
당신은 아마 Windows I/O Completion Ports 찾고 있습니다. SysInternals 명부터 article입니다.
스케일 러블 소켓 프로그래밍에 실제로 참여하는 경우 Windows에서 IO 완료 포트보다 성능이 좋은 것은 없습니다.
이렇게 말한 결과 프로그램은 완료 포트 모델에 대해 큰 재 작성이 필요할 것입니다.
그러나 select()/FD_ISSET을 사용해도 성능을 향상시킬 수 있습니다. winsock2.h의 FD_SET에서 소켓의 배열하고 FD_SET 소켓을 추가하는 찾을 수 winsock2.h에
typedef struct fd_set {
u_int fd_count; /* how many are SET? */
SOCKET fd_array[FD_SETSIZE]; /* an array of SOCKETs */
} fd_set;
또한 요소 카운터로 정의된다 : 여기
는 그것을 할 수있는 방법입니다 이 배열의 끝에서 FD_ISSET은 배열에서 선형 검색을 수행합니다. 당신이 소켓의 정렬 된 배열을 사용하는 매크로를 변경하면 지금
, 즉
다음 의존의 이진 검색을 수행하는 정렬 된 순서에 소켓을 추가 배열 FD_ISSET의 크기는 크게 향상 될 수 있습니다 (FD_SET의 성능은 다소 떨어지지 만 FD_SET는 거의 작동하지 않는다고 가정합니다).
유닉스에서 select()의 성능은 FD_SET 비트 맵이므로 FD_SET/FD_ISSET은 비트를 테스트하거나 설정하기 때문에 성능이 더 좋습니다. Windows에서는 소켓이 작은 양의 파일 설명자 번호가 아니기 때문에이 기술은 적용되지 않습니다. 이는 핸들이며 핸들의 스칼라 값은 클 수 있습니다.
나는이 유형의 'fix'를 사용하여 360에서 30 초로 성능을 얻었지만 HPUX가 걸리는 1 초 또는 2 초보다 여전히 느립니다. 코드의 n 제곱 섹션을 상당 부분 제거했습니다. –
그래, 이건 분명히 klugde, 좋은 해결책은 완료 포트 비동기 io 할 것입니다.WSAPoll() (Unix poll()과 비슷 함, Vista 이후 사용 가능)은 조사 할 가치가 있습니다. 처음 출시되었을 때 속도가 느린 것을 상기하지만 테스트에서 "최적화 된"select()보다 느립니다. 그 이후로 개선되었을 수도 있습니다. –
감사합니다. 정확하게 필요한 것 같습니다. 지금 결정해야 할 주요 사항은 I/O 완료 포트로 서버를 다시 구현하거나 자바를 사용하는 것입니다 (자바가 실행되는 서버의 50 %와 레거시 프로그램의 50 %를 이미 보유하고 있기 때문에). 30 년 된 코드를 상속하는 것을 좋아합니다. Windows 성능 문제를 해결하라는 메시지가 전달됨. –
기타 유용한 링크 - http://msdn.microsoft.com/en-us/library/aa365198.aspx - http://int64.org/2009/05/13/high -performance-io-on-windows –