Node.js/Express.js - 我应该把所有功能都包含在新的承诺中吗?

Ron*_*ton 1 javascript node.js express

Express文档生产最佳实践:性能和可靠性说:

不要使用同步功能

同步函数和方法会占用执行过程,直到它们返回为止.对同步函数的单次调用可能会在几微秒或几毫秒内返回,但在高流量网站中,这些调用会增加并降低应用程序的性能.避免在生产中使用它们.

所以我的问题是,在节点/快递的情况下,如果我有接受一些静态值,并返回一个计算结果的功能(我通常会考虑"同步功能"),是最好的做法是内换行功能a new Promiseresolve结果或是否会产生任何重大的不必要的开销?例如:

当前:

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

function myFunction(myArgument){
  var thisResult;
  //some calculations
  return thisResult;
}
Run Code Online (Sandbox Code Playgroud)

新的(和改进?)

//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)
    }
  });
}
Run Code Online (Sandbox Code Playgroud)

Ber*_*gur 5

简短的回答:没有.

该文档讨论的不是使用nodeJS文件系统的readfileSync或bcrypt.compareSync等函数的同步版本.同步调用阻止nodeJS中的事件循环.所以在等待同步调用完成时没有任何反应.这一方法完成后整个程序停止运行.这在像nodeJS这样的单线程系统中很糟糕.

没有理由用回调或承诺来包装只是简单计算或数组操作的函数.

它只是说,如果有一个提供同步版本方法的库/方法,请尽量避免使用该方法.

退房:https://nodejs.org/en/docs/guides/blocking-vs-non-blocking/

Node.js中的JavaScript执行是单线程的,因此并发性是指事件循环在完成其他工作后执行JavaScript回调函数的能力.任何预期以并发方式运行的代码都必须允许事件循环继续运行,因为正在发生非JavaScript操作,如I/O.

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

事件循环不同于许多其他语言中的模型,其中可以创建其他线程来处理并发工作.

关于将所有内容包装在promises中的额外开销.答案仍然是否定的.

你将体验到没有区别

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

const ans = sum(1,2)
console.log(ans) // 3
Run Code Online (Sandbox Code Playgroud)

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

sum(1,2).then(ans => {
  console.log(ans) //3
})
Run Code Online (Sandbox Code Playgroud)