Question

Express文档Production best practices: performance and reliability说：

不要使用同步功能

同步函数和方法将执行过程捆绑在一起，直到   他们回来了。单个调用同步函数可能会返回   几微秒或毫秒，但是在高流量的网站上，   这些调用加起来会降低应用程序的性能。避免他们   在生产中使用。

所以我的问题是，在node / express的上下文中，如果我有一个接受一些静态值并返回计算结果的函数（我通常将其视为“同步函数”），则最佳实践是包装该函数在new Promise和resolve内部的结果，还是会产生任何不必要的重大开销？例如：

当前：

//inside my index.js
var myArgument = 'some long string';
var myResult = myFunction(myArgument);

function myFunction(myArgument){
  var thisResult;
  //some calculations
  return thisResult;
}

新功能（已改进？）

//inside my index.js
(async function() {
var myArgument = 'some long string';
var myResult = await myFunction(myArgument);
});

function myFunction(url) {
  return new Promise((resolve, reject) => {
    var thisResult;
    //some calculations
    if(thisResult){
      resolve (thisResult);
    } else {
      reject (null)
    }
  });
}

Answer 1

简短的回答：不。

文档讨论的是不使用功能的同步版本，例如不使用来自nodeJS文件系统的readfileSync或bcrypt.compareSync。同步调用会阻塞nodeJS中的事件循环。因此，在等待同步调用完成时什么也不会发生。这一方法完成时，整个程序停止。在像nodeJS这样的单线程系统中，这很糟糕。

没有理由用回调或promise包装仅是简单计算或数组操作的函数。

这只是说，如果有一个库/方法提供该方法的同步版本，请尝试避免该方法。

签出：https://nodejs.org/en/docs/guides/blocking-vs-non-blocking/

Node.js中的JavaScript执行是单线程的，因此并发   指事件循环执行JavaScript回调的能力   完成其他工作后即可正常工作。预期的任何代码   以并发方式运行必须允许事件循环继续   正在像非JavaScript操作（例如I / O）一样运行。

作为示例，让我们考虑一种情况，其中每个对Web的请求   服务器需要50毫秒才能完成，其中50毫秒中的45毫秒是数据库I / O   可以异步完成。选择非阻塞异步   操作释放每个请求45毫秒的时间来处理其他请求。   仅通过选择使用，这是容量上的重大差异   非阻塞方法而不是阻塞方法。

事件循环与许多其他语言中的模型不同，其中   可能会创建其他线程来处理并发工作。

关于将所有内容包装在promise中的额外开销。答案是否定的。

您将不会有任何区别

function sum(x,y) {
  return x+y
}

const ans = sum(1,2)
console.log(ans) // 3

和

function sum(x,y) {
 return Promise.resolve(x+y) // Shorthand for your new Promise
}

sum(1,2).then(ans => {
  console.log(ans) //3
})

Node.js / Express.js-我应该将所有功能包装在一个新的承诺中吗？

不要使用同步功能

当前：

新功能（已改进？）

1 个答案: