2016-05-05 10 views
0

私が開発しているマルチプレイヤーゲーム用のバックエンドノードサーバーを作成しました。ほとんどの場合、各要求に約20〜100msかかることがあります。しかし、時には(たぶん50要求のうち1)私は同じ要求を行うだろうと解決するために2000 + msがかかります。質問時間が3〜4秒で時々取られる

サーバーは完全にnode.jsで書かれ、herokuでホストされています。私はmongooseを使用してデータベースへの呼び出しを行っています。

ここではログのスクリーンショットを示し、上部にはクエリが正常に機能する様子が示されています。リクエストは19:03:03.68で、レスポンスは19:03:03.73に送信され、19:03:03.74にすべてのデータが保存されます。 Herokuは要求を期待した結果である58msと見なします。

以下は、問題が発生したときです。 2つの別々のクライアントから複数の要求が届くことが分かります(各クライアントは1秒あたり〜1回の要求を送信します)。しかし、要求は蓄積され、約2000〜5000ms後にすばやく解決されます。私は多くの運がなければ問題を絞り込もうとしましたが、複数のリクエストが入ってくるのを見るとデータベースにクエリするときに関係していると思いますが、データベースへの最初のクエリは2300ms前後まで実際には解決しません。私の知る限り、これらの要求は、20〜100msで解決し、完全にランダムに発生する要求と同じです。

Console Log

実際のコードは、(この質問のために簡素化された)サーバー上で次のようになります。

console.log (“request received”); 
    Game.findOne({‘id’: gameID}, function(err, theGame){ 
     console.log("First Query"); 

データベースクエリを探すことのために、私はまた、モンゴシェルを開きました

db.system.profile.find({millis: {$gt : 2000} }).sort({ ts: 1}); 

ここには、関連するすべてのものが含まれているはずの少し修正された結果があります:

{ "op" : "update", "ns" : "theDb.players", "query" : 
    { "_id" : ObjectId("572b8eb242d70903005df0df") 
    }, "updateobj" : 
    { "$set" : 
    { "lastSeen" : ISODate("2016-05-05T18:19:30.761Z"), "timeElapsed" : 16 
    } 
}, "nscanned" : 1, "nscannedObjects" : 1, "nMatched" : 1, "nModified" : 1, "fastmod" : true, "keyUpdates" : 0, "writeConflicts" : 0, "numYield" : 0, "locks" : 
{ "Global" : 
    { "acquireCount": 
    { "r" : NumberLong(2), "w" : NumberLong(2) } 
    }, "MMAPV1Journal" : 
    { "acquireCount" : 
    { "w" : NumberLong(2) }, "acquireWaitCount" : 
    { "w" : NumberLong(1) }, "timeAcquiringMicros" : 
    { "w" : NumberLong(7294179) } 
    }, "Database" : 
    { "acquireCount" : 
    { "w" : NumberLong(2) } 
    }, "Collection" : 
    { "acquireCount" : 
    { "W" : NumberLong(1) } 
    }, "oplog" : 
    { "acquireCount" : 
    { "w" : NumberLong(1) } 
    } 
}, "milli" : 2298, "execStats" : {}, "ts" : ISODate("2016-05-05T18:19:33.060Z") 

2番目の結果:

{ "op" : "update", "ns" : "theDb.connections", "query" : 
    { "_id" : ObjectId("572b8eaf42d70903005df0dd") 
    }, "updateobj" : 
    { "$set" : 
    { "internalCounter" : 3, "lastCount" : 3, "lastSeen" : ISODate("2016-05-05T18:19:30.761Z"), "playerID" : 128863276517, "sinceLast" : 0 
    } 
    }, "nscanned" : 1, "nscannedObjects" : 1, "nMatched" : 1, "nModified" : 1, "keyUpdates" : 0, "writeConflicts" : 0, "numYield" : 0, "locks" : 
    { "Global" : 
    { "acquireCount" : 
     { "r" : NumberLong(2), "w" : NumberLong(2) 
     } 
    }, "MMAPV1Journal" : 
    { "acquireCount" : 
    { "w" : NumberLong(2) }, "acquireWaitCount" : 
     { "w" : NumberLong(1) }, "timeAcquiringMicros" : 
     { "w" :NumberLong(7294149) } 
    }, "Database" : 
    { "acquireCount" : 
     { "w" : NumberLong(2) } 
    }, "Collection" : 
    { "acquireCount" : 
     { "W" : NumberLong(1) } 
    }, "oplog" : 
    { "acquireCount" : 
     { "w" : NumberLong(1) } 
    } 
    }, "millis" : 2299, "execStats" : {},"ts" : ISODate("2016-05-05T18:19:33.061Z") 

私は本当にすべての要求のための待ち時間がゲーム自体では、それは非常に刺激性のそれ以外の場合は500ミリ秒を超えないようにする必要があります。私は本当にこれを引き起こしているかもしれないし、もっと理解する方法を失っている。

私は問題の原因は、timeAcquiringMicrosが長すぎると仮定しています。私はこれを引き起こしているのか分からない。

*クライアントが標準のhttp要求だけでデータを要求しているため、現在ソケットを使用していないことに注意してください。

答えて

2

申し訳ありませんが、私はついにこの問題を解決しました。問題は実際に私が行ったこととは関係がありませんでした。私はmlabがherokuと関連して提供しているサンドボックスプランを使用していました。私のアプリケーションはサンドボックスプランを使って他の人と処理時間を競い合うようになっていました。彼らの質問はデータベースの速度を落として、応答時間にそれらのスパイクを引き起こしていました。

解決策:共有クラスタプランにアップグレードする必要がありました。アップグレードして以来、私はクエリ時間に不規則性がありませんでした。

関連する問題