javascript - node.js request.js 不并行触发请求

Question

(我也将此作为问题发布在请求的 github 页面上 - link)

我有一个应用程序使用请求从内部 API 获取 API 数据。

我正在做一些测试，我们的应用程序在高负载下的扩展性似乎很差，而且 API 响应越来越慢。

我将其推断为我们正在使用的请求调用，看起来请求可能在队列中触发这些，而不是一次全部触发。这是一个显示此行为的测试脚本:

#!/usr/bin/env node
var request = require("request"),
    logger = require("./logger.js"),
    argv = require("optimist").argv;
var numRequests = argv.requests || argv.r,
    requestsMade = 0,
    wait = argv.wait || argv.w || 0,
    url = argv.url || argv.u || "http://www.google.com",
    requestApi = function(url,callback){
        var requestTime = new Date().getTime();
        request({
                method: "GET",
                uri: url
            },function(err, response, body){
                var totalTime = (new Date().getTime()) - requestTime;
                callback(err, response, body, totalTime);
        });
    },
    doRequest = function(){
        requestsMade++;
        if(requestsMade==numRequests) clearInterval(requestMaker);
        var thisRequest = requestsMade;
        logger.info("Firing Request #"+thisRequest);
        requestApi(url,function(err, response, body, totalTime){
            if(err){
                logger.error("error contacting API ", err, "trying to request ",reqUrl," after ", totalTime, "ms");
            } else {
                logger.info("Api responded to request #"+thisRequest+" after ", totalTime, "ms");
            }
        });
    };
logger.info("Starting Test with " + numRequests + " Requests.");
var requestMaker = setInterval(doRequest,wait);

(logger.js 只是一个用于打印时间戳和设置日志级别的日志记录工具)。

而且，谷歌的一个简单测试显示了增量减速:

$ node requestTester.js -r 20
[Wed 2011-11-2 11:2:24.575 GMT7] INF: Starting Test with 20 Requests.
[Wed 2011-11-2 11:2:24.580 GMT7] INF: Firing Request #1
[Wed 2011-11-2 11:2:24.654 GMT7] INF: Firing Request #2
[Wed 2011-11-2 11:2:24.661 GMT7] INF: Firing Request #3
[Wed 2011-11-2 11:2:24.664 GMT7] INF: Firing Request #4
[Wed 2011-11-2 11:2:24.667 GMT7] INF: Firing Request #5
[Wed 2011-11-2 11:2:24.672 GMT7] INF: Firing Request #6
[Wed 2011-11-2 11:2:24.673 GMT7] INF: Firing Request #7
[Wed 2011-11-2 11:2:24.674 GMT7] INF: Firing Request #8
[Wed 2011-11-2 11:2:24.675 GMT7] INF: Firing Request #9
[Wed 2011-11-2 11:2:24.675 GMT7] INF: Firing Request #10
[Wed 2011-11-2 11:2:24.676 GMT7] INF: Firing Request #11
[Wed 2011-11-2 11:2:24.677 GMT7] INF: Firing Request #12
[Wed 2011-11-2 11:2:24.678 GMT7] INF: Firing Request #13
[Wed 2011-11-2 11:2:24.679 GMT7] INF: Firing Request #14
[Wed 2011-11-2 11:2:24.680 GMT7] INF: Firing Request #15
[Wed 2011-11-2 11:2:24.681 GMT7] INF: Firing Request #16
[Wed 2011-11-2 11:2:24.682 GMT7] INF: Firing Request #17
[Wed 2011-11-2 11:2:24.683 GMT7] INF: Firing Request #18
[Wed 2011-11-2 11:2:24.684 GMT7] INF: Firing Request #19
[Wed 2011-11-2 11:2:24.685 GMT7] INF: Firing Request #20
[Wed 2011-11-2 11:2:25.257 GMT7] INF: Api responded to request #2 after  602 ms
[Wed 2011-11-2 11:2:25.621 GMT7] INF: Api responded to request #1 after  1041 ms
[Wed 2011-11-2 11:2:25.774 GMT7] INF: Api responded to request #3 after  1113 ms
[Wed 2011-11-2 11:2:25.779 GMT7] INF: Api responded to request #4 after  1115 ms
[Wed 2011-11-2 11:2:25.895 GMT7] INF: Api responded to request #5 after  1228 ms
[Wed 2011-11-2 11:2:26.378 GMT7] INF: Api responded to request #9 after  1703 ms
[Wed 2011-11-2 11:2:26.714 GMT7] INF: Api responded to request #7 after  2041 ms
[Wed 2011-11-2 11:2:26.870 GMT7] INF: Api responded to request #8 after  2196 ms
[Wed 2011-11-2 11:2:27.126 GMT7] INF: Api responded to request #10 after  2449 ms
[Wed 2011-11-2 11:2:27.267 GMT7] INF: Api responded to request #6 after  2595 ms
[Wed 2011-11-2 11:2:27.730 GMT7] INF: Api responded to request #14 after  3051 ms
[Wed 2011-11-2 11:2:28.68 GMT7] INF: Api responded to request #13 after  3389 ms
[Wed 2011-11-2 11:2:28.72 GMT7] INF: Api responded to request #11 after  3395 ms
[Wed 2011-11-2 11:2:28.75 GMT7] INF: Api responded to request #12 after  3398 ms
[Wed 2011-11-2 11:2:28.332 GMT7] INF: Api responded to request #16 after  3650 ms
[Wed 2011-11-2 11:2:28.471 GMT7] INF: Api responded to request #15 after  3791 ms
[Wed 2011-11-2 11:2:29.45 GMT7] INF: Api responded to request #18 after  4362 ms
[Wed 2011-11-2 11:2:29.161 GMT7] INF: Api responded to request #17 after  4479 ms
[Wed 2011-11-2 11:2:29.173 GMT7] INF: Api responded to request #19 after  4488 ms
[Wed 2011-11-2 11:2:29.424 GMT7] INF: Api responded to request #20 after  4738 ms

为什么会这样？是否有一个我错过的配置选项会立即触发所有请求？

我不想放弃请求，因为我非常喜欢它，但这是该项目的一个亮点。

Answer 1

如果您不想使用 v0.5.10(它已经接近稳定并且是即将到来的 Node v0.6.x 的候选者)，您将不得不修补请求。在请求 main.js 中，替换行

var globalPool = {}

与

var globalPool = false

这应该会消除对并发连接的限制。