2013-06-22 2 views
13

이 문제는 특별히 Nodejitsu와 관련이 있지만 다른 VPS에서도 이와 비슷한 결과가 발생합니다. socket.io를 사용하여 실시간 게임을하고 있는데, 한 가지 사실은 서버가 응답하기 전에 과도한 시간을 기다리는 경우가 있다는 것입니다. 이 기간 동안 여러 요청이 전송되면 마치 모든 요청이 대기 상태가되어 처리 된 것처럼 동작합니다. 나는 그것이 (VPS의 경우와 마찬가지로) 공유 된 하드웨어상의 다른 사용자들의 존재와 모호하게 관련되어 있다고 생각한다. NodeJS를 사용한 높은 대기 시간

express = require('express') 
http = require('http') 

app = express() 
server = http.Server(app) 

io = require('socket.io').listen(server) 

io.sockets.on('connection', function(sock){ 
    sock.on('perf', function(data, cb){ 
     cb([Date.now()]); //respond with the current time 
    }) 
}) 

app.get('/', function(req, res){ 
    res.header("Access-Control-Allow-Origin", "*") 
    res.header("Access-Control-Allow-Methods", "HEAD,GET,PUT,POST,DELETE") 
    res.header("Access-Control-Allow-Headers", "X-Requested-With") 

    res.end(JSON.stringify([Date.now().toString()])); //http equivalent of perf function 
}) 

server.listen(process.env.PORT || 6655, function(){ 
    console.log('listening now') 
}) 

내가 소켓 간단한 빈 HTML 페이지를했다 :이 테스트 (그리고 내 게임의 코드 때문이 아니었다 있는지 확인) 어쨌든

, 나는 최소한의 테스트 케이스를 만들었습니다. io는 주기적으로 perf 이벤트와 콜백을 시작하는 데 걸린 시간을 보냅니다. 바 길이는 시간이 아닌 선형 양의 제곱근을 나타내는

graph showing lag spike

참고 : 그리고 그것은 여전히 ​​같은 일을 보여줍니다.

socket.io를 사용하는 대신 XHR을 사용하여 현재 응답 시간을 유사한 방식으로 측정합니다. 그 결과는 매우 유사합니다. 대기 시간이 짧은 응답이 많습니다 (웹 소켓보다 기준선이 높지만 예상대로).) 그리고 때로는 쌓인 것으로 보이는 가끔씩의 스파이크가 있습니다.

이상한 점은 여러 브라우저 창과 다른 브라우저에서 열면 여러 브라우저간에 상관 관계가있는 것 같습니다 (일부 서버에서는 완전히 부재하거나 빈번하지 않음). 이는 서버 측 현상이라는 것을 암시합니다. 그러나 일부 브라우저에서는 대기 시간이 급상승하지만 다른 세션에서는 발생하지 않으며 동일한 세션의 두 개의 Chrome 창은 사실상 정확한 중복으로 보입니다. 이는 로컬 또는 컴퓨터별로 또는 브라우저별로, 슬기로운).

왼쪽에서 오른쪽

: 크롬 시크릿, (일반) 크롬, 파이어 폭스,

charts on four windows

어쨌든,이 달 동안 저를 혼란 된 내가 정말 무엇을 이해하고 싶습니다 (일반) 크롬 그것과 그것을 고치는 방법을 일으키는 것입니다.

+1

서버에서 로컬 연결을 (예 : phantomjs와 같은 것으로) 직접 열고 유사한 측정 값이 표시되는 경우 동일한 측정을 수행 할 수 있는지 궁금합니다. 또한 사용중인 브라우저의 버전과 플래시, 긴 폴링 또는 iframe으로 떨어지는 브라우저인지 궁금합니다. 세션 없이도 익스프레스를 실행하는 것처럼 보이므로 세션 관련 GC 또는 이와 유사한 것으로 보이지 않으며 서버가 재시작 중이 지 않은 것으로 나타났습니다 (모든 브라우저에서 급증 할 수도 있음). 같은 시간, 그렇게 아마 아닙니다,하지만 물어보십시오). – hoonto

+0

나는이 기간 동안 이미 서버 통계를 모니터링하고있는 것으로 추측하고 있습니까? 메모리 또는 CPU에 상관 관계가있는 스파이크 또는 드롭이 동시에 발생하는 경우 궁금합니다. 데이터 센터에 액세스 할 수 있다면 로컬 스위치에 꽂아 네트워크 간섭을 대부분 제거 할 수 있지만 옵션이 아닙니다 ... 데이터 내부에서 socket.io 모니터링 서비스를 제공하면 좋을 것입니다 센터. – hoonto

+1

사실, 로컬 socket.io 노드 클라이언트를 작성하고 동일한 서버에서 로컬로 실행하고 측정 할 수도 있습니다. 미안하지만, 성능 문제는 건초 더미에서 바늘처럼 느껴질 수 있습니다. 그래서 생각할 수있는 모든 것을 버리려고하면 문제를 특정 영역으로 좁히는 데 도움이 될 수 있습니다. – hoonto

답변

0

이상하게 들리 겠지만 노드와 문제는 아니지만 OS 설정을 고려해야합니다. OS가 소켓에 보여주고있는 파일 핸들과 연결 수를 확인 했습니까? OS의 소켓 타임 아웃이 충분히 낮았는지 확인 했습니까? 다른 코드와 비슷한 성능 문제가 발생했으며 코드가 아닌 OS로 판명되었습니다. 또한 패키지를 확인하고 소켓에서 열린 허용 연결에 대한 내용을 확인하십시오. 나는 노드 코드를 보지 않았지만 java의 http 클라이언트 라이브러리와 비슷한 문제에 부딪쳤다. 응용 프로그램이 방금 백업되었고 연결 수가 많은 구성 문제였습니다.

1

당신은 CPU 또는 램 문제가 있는지 확인했다고 가정합니다.

"놀라운"방식으로 노드를 느리게 할 수있는 유일한 방법은 가비지 컬렉터입니다. --trace*과 함께 노드를 실행하여 무슨 일이 일어나는지보십시오. (node --v8-options을 참조하십시오.)

나는 개인적으로 그 점을 발견하지 못했다고 생각합니다. 왜냐하면 - 그게 내 느낌입니다 - 문제는 다른 곳에서 발생하기 때문입니다.

곱하기 500ms의 완벽한 지연으로 패킷 손실이 있다고 가정합니다. ifconfig이 일반적인 문제인지 확인한 다음 tcpdump 패킷을 확인하고 패킷이 재전송되는지 확인하십시오.

+0

노드로 조금만 해봤지만 자바 서버 코드를 꽤 많이 작성했습니다. 대기 시간이 걱정되는 주요 원인 중 하나는 가비지 수집입니다. Javascript/Node와 같은 많은 VM 기반 언어의 문제점은 대기 시간이 VM이 허용하는 것처럼 예측할 수 있다는 것입니다. Java의 경우, 가비지 수집을 최소화하기 위해 열심히 노력할 것입니다. 대기 시간 때문이 아니라 대기 시간 급상승 때문입니다. 혹시라도 GC를 살펴 보겠습니다. – sasbury

0

당신이 이것을 보는 이유는 Nagle 's Algorithm 때문입니다. 이것은 잠시 동안 데이터를 버퍼링 한 다음 더 큰 데이터 청크를 보내는 I/O에서 사용되는 알고리즘입니다. 전송 (소켓)을 저장하는 데 사용됩니다. 여기에 대해 더 많이 읽을 수 있습니다 http://en.wikipedia.org/wiki/Nagle's_algorithm

Nagle의 알고리즘을 비활성화하려면 (작은 요청을 가능한 빨리 보내려면 좋음) socket.setNoDelay (true); net.Socket()을 사용하고 있다면. socket.io의 경우 Nagle은 기본적으로 Websocket에 대해 기본적으로 비활성화되어 있지만 다른 프로토콜에는 사용할 수 없습니다. node.js에서 net.Sockets로 테스트를 실행하고, Nagle을 비활성화하고, 얻은 결과를 확인하는 것이 좋습니다.

+3

Nagle은 연결 단위로만 작동하고 작은 패키지는 큰 패키지로 연결합니다. 모든 단일 통화에 대해 새로운 연결을 설정 했으므로 여기에는 문제가 될 수 없습니다. Nagle은 실시간 스트리밍을 할 때만 문제가 될 수 있습니다. – CFrei

관련 문제