2012-10-15 2 views
3

실시간 알림 시스템을 구축하고 있습니다. 이것은 웹 애플리케이션의 일부이지만 이벤트는 발생 즉시보아야합니다. 긴 폴링은 옵션이 없었습니다. 웹 서버가 이벤트를 사용할 수 없을 때 연결을 유지하는 것이 비용이 많이 들었 기 때문입니다. 그래서 짧은 폴링을해야했습니다.높은 클라이언트 폴링 속도에 대한 웹 서버 허용치 : 카우보이 대 Yaws 웹 서버

각 클라이언트는 2 초마다 웹 서버에 도달합니다 (비교적 빠른 속도입니다). 이벤트를 사용할 수있게되면 JSON으로 JavaScript 클라이언트에 전송됩니다. 이제는 짧은 수명의 연결을 처리하기 위해 서버를 설정해야합니다. 필자는 Yaws 웹 서버를 사용하여 이러한 시스템을 구현했습니다. 그러나 Yaws는 많은 다른 많은 서비스를 시작하기 때문에 무겁고 연결이 30,000을 넘을 때 거절되거나 중단되기 시작합니다 (어쩌면 Yaws가 실행중인 동일한 Erlang VM에서 일부 ETS 테이블을 실행하기 때문에 [ 이들을 분리하려면 rpc:call/4이 필요할 수 있으며, 이는 대기 시간을 증가시킬 수 있습니다.) 나는 운영 체제에 특정한 조작을해야한다는 것을 알고 있으며, 그것들은 완료되었습니다.

여러 개의 Yaws 인스턴스를 클러스터링하기가 쉽다면 문제가되지 않습니다. Yaws에서는 몇 가지 appmods를 사용하고 있으며, 나는 RESTfully 일을하고있다. 나는 카우보이 웹 서버가 약간의 것들을 향상시킬 것이라고 생각했다. 나는 전에 카우보이를 사용하지 않았지만 나는 미스 타틴을 사용했다. Cowboy를 살펴보면 완전한 OTP 애플리케이션이며 클러스터링이 쉬우 며 경량이기 때문에 전체 시스템에서 처리 할 수있는 클라이언트 수가 증가 할 수 있습니다. 스토리지는 Mnesia에 있으며, 더 많은 노드를 추가하기 위해 쉽게 배포 할 수 있습니다 (아마도 복제로). 따라서 모든 Mnesia 인스턴스 앞에 카우보이 인스턴스가 있습니다.

내 질문은 :

  1. 내가 카우보이에 딸기 종에서 전환 한 경우, 나는 크게 성능을 향상시킬 수 있다는, 내 추측이 맞습니까?

  2. Yaws는 Appmods#arg{} 레코드를 통해 깨끗한 API를 제공합니다. 카우보이는이 두 가지에 상응하는 것을 가지고 있습니까?

  3. Cowboy 파일 업로드를 처리 할 수 ​​있습니까? 그렇다면 빈번한 파일 업로드의 경우 어떤 서버 (Yaws 또는 Cowboy)를 사용하는 것이 더 좋을까요? 카우보이로 파일을 업로드하는 방법을 설명하십시오.

  4. 동일한 기계에서 여러 개의 Yaws 인스턴스를 실행할 수 있습니다. 서버 (물리적 상자) 당 많은 Yaws 인스턴스를 생성하고이를 통해 클라이언트로드를 분산 시키면 도움이 될 것이라고 생각합니까? 이 일에 대해 알아야 할 것은 무엇입니까?

  5. yaws.conf 매개 변수를 max_connections = nolimit으로 설정하면 어떻게 카우보이에서 동일하게 지정합니까?

지금, 나는 interview with Cowboy author을 따라 카우보이가 딸기 종보다 더 가볍고 왜 그가 이유를 설명합니다. 그는 이렇게 말합니다

가장 큰 차이점은 목록 대신 바이너리를 사용한다는 것입니다. 일반 수용기 풀은 다른 것입니다. 나는 다른 많은 작은 차이점을 나열 할 수 있지만, 나는 이것이 가장 흥미롭지 않다고 생각한다.

왜냐하면 카우보이는 리스너 풀 라이브러리 Ranch을 사용하기 때문에 더 많은 연결을 처리 할 수있는 더 높은 기능과 함께 목록이 아닌 바이너리를 사용하게됩니다.

같은 인터뷰에서 또 다른 인용 : 우리가 대신 두 연결 당 하나 개의 프로세스를 사용하고, 우리가 대신 목록의 바이너리를 사용하기 때문에

, 우리는 사용자의 개입없이 다른 프로젝트보다 훨씬에게 적은 메모리를 사용하게 . 카우보이도 게으르고, 필요한 경우를 제외하고는 아무 것도하지 않습니다. 따라서 우리는 사용자가 함수 호출을 시작할 때까지 메모리에 많은 양을 가지고 있지 않습니다.

yaws가이 사건을 어떻게 처리하는지 궁금합니다. 여하튼, 문제 도메인에 경량 HTTP 처리가 필요합니다. Yaws가 Mochiweb, Misultin 또는 Cowboy와 비교하여 더 많은 메모리 소비를 발생시키는 것은 사실입니다. 가장 큰 우려는 Yaws가 가장/가장 깨끗한 API를 가지고 있기 때문에 Erlang 레코드로 필요한 모든 것을 포함하는 #arg{}에 액세스 할 수 있으므로 외부에서 물건을 추출 할 수있는 수많은 기능을 가진 다른 사용자보다 Erlang 레코드로 가져올 수 있습니다. 심지어 설명서 : Yaws 문서는 꽤 훌륭하고 간단합니다. 아마도 나는 파일 업로드와 단순한 GETPOST 요청 처리와 같은 것들에 대해 더 많은 카우보이 코드를 살펴볼 필요가있을 것입니다.

그렇지 않으면 이전에 질문 한 질문 사항이 여전히 긴급한 문제로 남아 있습니다. Yaws는 꽤 좋지만 빠른 속도로 가벼운 단명 높은 여론 조사 상황에 과잉 인 것처럼 보입니다. 어떻게 생각하십니까?

+1

"이유"가 내려야합니다. 다른 의견을 요구하는 모든 질문에 투표가 내려집니다. 나는 그 이유가 무엇인지 궁금합니다. 누군가이 질문에 왜 투표가 내려 졌는지 설명합니다. 당신이 대답이 없다면 왜이 페이지에서 '이길 수 없습니까? 아? –

+0

나는 당신이 쓴 것의이 부분을 이해하지 못합니다 : "... yaws는 많은 다른 많은 서비스를 시작합니다 ..."Yaws는 감독자, 로거 등 8 가지 프로세스를 등록합니다. 나에게 "많은 다른 많은 서비스"가 될 자격이 없다. –

+0

yaws 인스턴스를 클러스터링하는 데 어떤 문제가 있는지 설명 할 수 있습니까? –

답변

3

귀하의 30000 거부 제한은 어딘가에 32k 한도와 매우 흡사합니다. 기본 프로세스 수 (32k) 또는 파일 디스크립터 (file descriptor)의 시스템 한계 (system limit). 제한이 커널 측면에있을 가능성을 배제해서는 안됩니다. 필자는 커널 설정으로 인해 시스템이 매우 쉽게 한계에 도달하는 것을 보았습니다.

관련 문제