fs.readFileSync 似乎比 fs.readFile 快 - 可以用于生产中的 Web 应用程序吗? [英] fs.readFileSync seems faster than fs.readFile - is it OK to use for a web app in production?
问题描述
我知道在 node 中开发时，您应该始终尽量避免阻塞(同步)函数并使用异步函数，但是我进行了一些测试以了解它们的比较.
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 倍，加载一个 50KB 的 json 文件(缩小)大约需要 1 毫秒.我所有的 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 的连接会等待而不会进行任何处理.这里是法尔维尔.
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屋！
