fs.readFileSync似乎比fs.readFile更快 - 在生产中用于Web应用程序是否可以？ [英] fs.readFileSync seems faster than fs.readFile - is it OK to use for a web app in production?

问题描述

我知道在开发节点时，你应该总是尝试避免阻塞（同步）函数并使用异步函数，但我会稍微测试一下它们的比较方法。

I know that when developing in node, you should always try to avoid blocking (sync) functions and go with async functions, however I a little test to see how they compare.

我需要打开一个包含i18n数据（如日期和时间格式等）的json文件，并将该数据传递给使用此数据格式化我的视图中的数字等的类。

I need to open a json file that contains i18n data (like date and time formats, etc) and pass that data to a class that uses this data to format numbers etc in my views.

在回调中开始包装所有类的方法会有点尴尬，所以如果可能的话，我会使用同步版本。

It would be kind of awkward to start wrapping all the class's methods inside callbacks, so if possible, I would use the synchronous version instead.

console.time('one');
console.time('two');
fs.readFile( this.dir + "/" + locale + ".json", function (err, data) {
  if (err) cb( err );
  console.timeEnd('one');
});
var data = fs.readFileSync( this.dir + "/" + locale + ".json" );
console.timeEnd('two');

这导致我的控制台中出现以下行：

This results in the following lines in my console:

two: 1ms
one: 159ms

似乎fs.readFileSync比fs.readFile快约150倍，并且需要大约1ms才能加载50KB的json文件（缩小）。我所有的json文件都在50-100KB左右。

It seems that fs.readFileSync is about 150 times faster than fs.readFile and takes about 1ms to load a 50KB json file (minified). All my json files are around 50-100KB.

我想也许以某种方式将这个json数据记忆或保存到会话中，这样每个会话只读取一次文件（或者当用户更改其区域设置时）。我不完全确定如何做到这一点，这只是一个想法。

I was thinking also maybe somehow memoizing or saving this json data to session so that the file is read only once per session (or when the user changes their locale). I'm not entirely sure how to do that, it's just an idea.

是否可以使用 fs.readFileSync 在我的情况下还是我以后会遇到麻烦？

Is it okay to use fs.readFileSync in my case or will I get in trouble later?

推荐答案

不，使用阻止API调用是不行的在您描述的节点服务器中。您的网站对许多并发连接的响应将受到巨大冲击。它也只是公然违反节点的＃1原则。

No, it is not OK to use a blocking API call in a node server as you describe. Your site's responsiveness to many concurrent connections will take a huge hit. It's also just blatantly violating the #1 principle of node.

节点工作的关键是，当它在等待IO时，它正在进行CPU /内存处理。同时。这需要专门的异步调用。因此，如果您有100个客户端读取100个JSON文件，节点可以要求操作系统读取这100个文件，但在等待操作系统返回文件数据时，节点可以处理这100个网络请求的其他方面。如果您在其中有一个同步调用，则所有客户端处理在该操作完成时完全停止。因此，当您按顺序读取客户端1,2,3,4等文件时，客户端编号100的连接将等待，无需任何处理。这是Failville。

The key to node working is that while it is waiting on IO, it is doing CPU/memory processing at the same time. This requires asynchronous calls exclusively. So if you have 100 clients reading 100 JSON files, node can ask the OS to read those 100 files but while waiting for the OS to return the file data when it is available, node can be processing other aspects of those 100 network requests. If you have a single synchronous call in there, ALL of your client processing stops entirely while that operation completes. So client number 100's connection waits with no processing whatsoever while you read files for client 1, 2, 3 , 4 and so on sequentially. This is Failville.

这是另一个类比。如果你去了一家餐馆并且是唯一的顾客，如果一个人坐在你身边，接受你的订单，煮熟，送给你，并且没有与主人打交道的协调费用，你可能会得到更快的服务。女主人，服务员，主厨，线厨师，收银员等。然而，在餐厅有100名顾客，额外的协调意味着事情并行发生，餐厅的整体响应能力超出了单身人士的情况。试图自己处理100个客户。

Here's another analogy. If you went to a restaurant and were the only customer, you would probably get faster service if a single person sat you, took your order, cooked it, served it to you, and handled the bill without the coordination overhead of dealing with host/hostess, server, head chef, line cooks, cashiers, etc. However, with 100 customers in the restaurant, the extra coordination means things happen in parallel and overall responsiveness of the restaurant is increased way beyond what it would be if a single person was trying to handle 100 customers on their own.

这篇关于fs.readFileSync似乎比fs.readFile更快 - 在生产中用于Web应用程序是否可以？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！