小编Hon*_*ule的帖子

在处理对时间敏感的项目时,我使用下面的代码测试可用的时序事件的粒度,首先在我的桌面计算机上测试Firefox,然后在我的Linux服务器上测试node.js代码.Firefox运行产生了可预测的结果,在1ms超时时平均为200 fps,并指示我有5ms粒度的时序事件.

现在我知道,如果我使用超时值0,则构建的Chrome V8引擎Node.js实际上不会将超时委托给事件,而是立即处理它.正如预期的那样,这些数字平均为60,000 fps,显然在CPU容量处理(并通过top验证).但是,在1ms超时的情况下,数字仍然在每秒3.5-4,000个周期()之间,这意味着Node.js不可能尊重1ms超时,这将产生理论上每秒最多1000次循环().

玩一系列数字,我得到:

• 2ms:~100 fps(真正的超时,表示Linux上10ms的定时事件粒度)
• 1.5:相同
• 1.0001:相同
• 1.0:3,500 - 4,500 fps
• 0.99:2,800 - 3,600 fps
• 0.5:1,100 - 2,800 fps
• 0.0001:1,800 - 3,300 fps
• 0.0:~60,000 fps

setTimeout(func,0)的行为似乎是可以原谅的,因为ECMAScript规范可能没有承诺setTimout将调用委托给实际的OS级中断.但任何0 <x <= 1.0的结果显然都是荒谬的.我给出了明确的延迟时间,n次呼叫的理论最小时间应为(n-1)*x.V8/Node.js到底在做什么？

var timer, counter = 0, time = new Date().getTime();

function cycle() {
    counter++;
    var curT = new Date().getTime();
    if(curT - time > 1000) {
        console.log(counter+" fps");
        time += 1000;
        counter = 0;
    }
    timer = setTimeout(cycle, 1);
}

function stop() {
    clearTimeout(timer);
}

setTimeout(stop, 10000);
cycle();

我正在编写一个RESTful API,其中包含一些端点,客户端可以将这些端点PUT或POST分块文件(使用flow.js),包括元数据中的有效负载摘要.服务器还会计算摘要,如果摘要不匹配,则会抛出错误,在这种情况下,客户端应尝试重试相同的请求而不做任何更改(至少在达到某个重试限制之前).

根据定义,所有标准代码似乎都不合适.什么是最好的代码？是否有任何符合惯例？

注意:出于与此库集成的目的,响应不能是404,415,500或501,因为它们将取消较大的操作而不是重试此部分.

我也不能使用409,因为它被用于识别上传同一文件的多个副本的尝试,我相信这更好地使用409.