Mongodb 副本集读取首选项仍然很慢

Mongodb 副本集读取首选项仍然很慢,mongodb,mongoose,replicaset,Mongodb,Mongoose,Replicaset,注意:我也有。我不确定这个问题属于哪里。如果它不在这里,告诉我,我会删除它 我正在测试我的副本集,特别是读取首选项,即使使用最近的读取首选项集,我仍然会得到缓慢的读取 对于这个问题,我们可以假设有2个mongodb实例(实际上有3个)。初选在阿姆斯特丹(AMS)。中学在新加坡(SG) 在我运行测试脚本的这两个位置(node+mongoose),我还有两台应用服务器 如果我运行 简单的查找查询,我在不到一秒钟的时间内得到一个响应 但是,如果我在SG中从我的应用程序服务器运行相同的查询,我会得到大约

注意:我也有。我不确定这个问题属于哪里。如果它不在这里,告诉我,我会删除它

我正在测试我的副本集,特别是读取首选项,即使使用最近的读取首选项集,我仍然会得到缓慢的读取

对于这个问题,我们可以假设有2个mongodb实例(实际上有3个)。初选在阿姆斯特丹(AMS)。中学在新加坡(SG)

在我运行测试脚本的这两个位置(node+mongoose),我还有两台应用服务器

  • 如果我运行 简单的查找查询,我在不到一秒钟的时间内得到一个响应
  • 但是,如果我在SG中从我的应用程序服务器运行相同的查询,我会得到大约4-7秒的响应时间

  • 如果我只是从SG app server连接到SG SECONDARY,我的查询时间会下降到输出中的信息表示数据库服务器正在快速处理查询。因此,这个问题可能不在数据库本身,可能在客户端

    您是否多次运行同一查询并对每次执行计时


    我怀疑这可能是由于MongoDB客户端的一些初步发现——如果最初没有命中每个节点并计时响应,如何在响应之前知道最接近的节点是什么?

    是的。运行1k个顺序查询的实验(只在前一个查询完成后才开始下一个查询)表明第一个查询很慢。随后的测试需要一个可接受的速度才能完成。
    mongoose.connect(configDB.url); 
    var start = new Date().getTime();
    Model.find({})
    .exec(function(err, betas){
        var end = new Date().getTime();
        var time = end - start;
        console.log(time/1000);
        console.log('finished');
        console.log(betas.length);
    });
    
    module.exports = {
         'url' : 'user:pwd@ip-primary/db,user:pwd@ip-secondary/db,user:pwd@ip-secondary/db'
    }
    
    var betaSchema = mongoose.Schema({
        .. some fields
    }, { read: 'n' });
    
    2015-09-16T07:49:23.120-0400 D COMMAND  [conn12520] run command db.$cmd { listIndexes: "betas", cursor: {} }
    2015-09-16T07:49:23.120-0400 I COMMAND  [conn12520] command db.$cmd command: listIndexes { listIndexes: "betas", cursor: {} } keyUpdates:0 writeConflicts:0 numYields:0 reslen:296 locks:{ Global: { acquireC
    ount: { r: 2 } }, MMAPV1Journal: { acquireCount: { r: 1 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { R: 1 } } } 0ms
    
        2015-09-16T07:49:19.368-0400 D QUERY    [conn11831] [QLOG] Running query:
    ns=db.betas limit=1000 skip=0
    Tree: $and
    Sort: {}
    Proj: {}
    2015-09-16T07:49:19.368-0400 D QUERY    [conn11831] Running query: query: {} sort: {} projection: {} skip: 0 limit: 1000
    2015-09-16T07:49:19.368-0400 D QUERY    [conn11831] [QLOG] Beginning planning...
    =============================
    Options = INDEX_INTERSECTION KEEP_MUTATIONS
    Canonical query:
    ns=db.betas limit=1000 skip=0
    Tree: $and
    Sort: {}
    Proj: {}
    =============================
    2015-09-16T07:49:19.368-0400 D QUERY    [conn11831] [QLOG] Index 0 is kp: { _id: 1 } io: { v: 1, key: { _id: 1 }, name: "_id_", ns: "db.betas" }
    2015-09-16T07:49:19.368-0400 D QUERY    [conn11831] [QLOG] Index 1 is kp: { email: 1 } io: { v: 1, unique: true, key: { email: 1 }, name: "email_1", ns: "db.betas", background: true, safe: null }
    2015-09-16T07:49:19.368-0400 D QUERY    [conn11831] [QLOG] Rated tree:
    $and
    2015-09-16T07:49:19.368-0400 D QUERY    [conn11831] [QLOG] Planner: outputted 0 indexed solutions.
    2015-09-16T07:49:19.368-0400 D QUERY    [conn11831] [QLOG] Planner: outputting a collscan:
    COLLSCAN
    ---ns = db.betas
    ---filter = $and
    ---fetched = 1
    ---sortedByDiskLoc = 0
    ---getSort = []
    2015-09-16T07:49:19.368-0400 D QUERY    [conn11831] Only one plan is available; it will be run but will not be cached. query: {} sort: {} projection: {} skip: 0 limit: 1000, planSummary: COLLSCAN
    2015-09-16T07:49:19.368-0400 D QUERY    [conn11831] [QLOG] Not caching executor but returning 109 results.
    2015-09-16T07:49:19.368-0400 I QUERY    [conn11831] query db.betas planSummary: COLLSCAN ntoreturn:1000 ntoskip:0 nscanned:0 nscannedObjects:109 keyUpdates:0 writeConflicts:0 numYields:0 nreturned:109 resl
    en:17481 locks:{ Global: { acquireCount: { r: 2 } }, MMAPV1Journal: { acquireCount: { r: 1 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { R: 1 } } } 0ms