Development Tip

실시간 웹 애플리케이션을위한 짧은 폴링과 긴 폴링?

yourdevel 2020. 12. 11. 20:24
반응형

실시간 웹 애플리케이션을위한 짧은 폴링과 긴 폴링?


실시간 웹 애플리케이션을 구축하고 있습니다. 제가 아는 한 가장 인기있는 선택은 짧은 폴링과 긴 폴링입니다. 서로를 측정하는 데있어 장단점은 무엇입니까?


  • 짧은 폴링 (일명 AJAX 기반 타이머) :

    장점 : 서버 소모가 아니라 간단합니다 (요청 사이의 시간이 긴 경우).
    단점 : 서버 이벤트가 지연없이 발생할 때 알림을 받아야하는 경우에는 좋지 않습니다. ( ItsNat 기반)

  • 긴 폴링 (XHR 기반 Comet)

    장점 : 서버 이벤트가 지연없이 발생하면 알림을받습니다. 단점 : 더 복잡하고 더 많은 서버 리소스가 사용됩니다. (ItsNat 기반)


논쟁을 위해서.

둘 다 http 요청 (xhr)이며 적어도 부분적으로 사실이 아닌 경우 더 많은 서버 리소스를 사용합니다 (기술에 전적으로 의존하며 나중에 설명 할 것임).

짧은 폴링.

서버에 올 때 처리되는 많은 요청. 많은 트래픽을 생성합니다 (리소스를 사용하지만 응답이 다시 전송되는 즉시 해제).

00:00:00 C-> Is the cake ready? 
00:00:01 S-> No, wait.
00:00:01 C-> Is the cake ready?
00:00:02 S-> No, wait.
00:00:02 C-> Is the cake ready? 
00:00:03 S-> Yeah. Have some lad.
00:00:03 C-> Is the other cake ready? ..

긴 폴링

하나의 요청이 서버로 이동하고 클라이언트가 응답이 올 때까지 기다리고 있습니다 (해결되지 않음). php / apache가있는 서버의 경우 처리 할 생성 된 스레드를 의미하며 완료 될 때까지 리소스를 예약합니다. 따라서 트래픽은 적지 만 리소스를 빠르게 소모하거나 리소스를 차단합니다. 그러나 예를 들어 Node (또는 다른 비동기 접근 방식-예를 들어 C ++ qt)를 사용하면 잠재적으로 리소스 사용량을 최소화 할 수 있습니다 (http 요청에 대한 응답 개체를 저장하고 작업이 준비 될 때 사용).

12:00 00:00:00 C-> Is the cake ready? 
12:00 00:00:03 S-> Yeah.Hame some lad.
12:00 00:00:03 C-> Is the cake ready? 

이를 짧은 폴링과 비교하면 잠재적으로 짧은 폴링에서 더 많은 전송을 사용했지만 해당 3 초 동안 실제로 처리 시간이 1.5 초 걸린다는 것을 알 수 있습니다 (호출 사이에 무언가 실행될 수 있음을 의미합니다). 긴 폴링의 경우 항상 동일한 리소스가 사용되었습니다. 이제 일반적으로 모든 libs가있는 PHP는 4MB 메모리로 시작합니다. 그러면 프레임 워크가 4-20MB입니다. 1024MB RAM을 사용할 수 있다고 가정합니다 (무료). 비관적으로 말하고 하나의 php instace 당 25MB를 사용한다고 가정하십시오. 이는 긴 폴링 연결 스크립트를 40 개까지만 얻을 수 있음을 의미합니다.

노드가 인스턴스를 생성하지 않기 때문에 (작업자 등을 사용하지 않는 한) 노드가 잠재적으로 훨씬 더 많은 서비스를 제공 할 수있는 이유입니다. 따라서 동일한 메모리를 사용하면 쉽게 10k 연결이 중단 될 수 있습니다. CPU가 올 때와 잠재적으로 출시 될 때 급증 할 수 있지만 유휴 상태 일 때는 거기에없는 것과 같습니다 (노드 / C ++에 보관할 메모리 구조에 대해서만 비용을 지불합니다).

웹 소켓

이제 클라이언트 안팎으로 몇 가지만 보내려면 웹 소켓 (ws 프로토콜)으로 이동하십시오. 첫 번째 호출은 http 요청의 크기이지만 나중에 클라이언트에서 서버 (새 질문) 및 서버에서 클라이언트 (답변 또는 푸시-연결된 모든 클라이언트에 대해 브로드 캐스트 가능)로 메시지 만 보냅니다. php websocekts libs가 있지만 다시 한 번 노드 또는 C ++와 같은 다른 기술을 사용하는 것이 좋습니다.

socket.io와 같은 일부 라이브러리에는 자체 계층 구조가 있으므로 websocket이 실패하면 긴 폴링 또는 짧은 폴링으로 돌아갑니다.

사용시기.

짧은 폴링 -음, 절대 ^^.

긴 폴링 -잠재적으로 서버와 단일 호출을 교환하고 서버가 백그라운드에서 일부 작업을 수행하는 경우. 또한 더 이상 동일한 페이지에서 서버를 쿼리하지 않을 때. 또한 긴 폴링 연결을 처리하기 위해 php를 레이어로 사용하지 않는 경우 (node ​​/ c ++는 단순한 중간 레이어가 될 수 있음). 긴 폴링은 정말 유익 할 수 있지만 그렇게 할 때만 가능합니다.

Websocket- 잠재적으로 서버와 하나 또는 두 번 이상의 호출을 교환하거나 이메일 알림 또는 무언가와 같이 예상하지 않았거나 요청하지 않은 서버에서 올 수 있습니다. 기능에 따라 다른 "방"을 계획해야합니다. 자바 스크립트의 이벤트 기반 특성을 받아들입니다.]


데이터베이스 기반의 실시간 애플리케이션을 얻으려면 ajax long poll과 comet 조합을 사용할 수 있습니다. 긴 설문 조사는 귀하의 대역폭에 대한 정말 좋은 사용자의 전송 요청 사용자가 MB 또는 인터넷 connection.For 예제의 일종처럼 그것을 지불 할 때 또한 사용자 MB.Because 정말 유용 짧은 여론 조사 는 당 요청을 보내는처럼 뭔가를 할 때 두 번째 사용자 인터넷 사용량은 각 연결 사용자가 비용을 지불하기 때문에 더 많을 것입니다 (사용자가 Mb를 느슨 함을 의미 함). 긴 폴링에서는 사용자가 새 메시지에 대해서만 비용을 지불합니다.

Websocket 은 정말 좋은 것입니다.하지만 Websocket은 새로운 버전의 브라우저를위한 것이기 때문에 많은 사람들이 채팅 시스템을 사용할 수 없다는 큰 문제를 생각해야합니다.

참고 URL : https://stackoverflow.com/questions/4642598/short-polling-vs-long-polling-for-real-time-web-applications

반응형