Menu
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.
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 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.
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.
Is it okay to use fs.readFileSync in my case or will I get in trouble later?
231
In fs. readFile() method, we can read a file in a non-blocking asynchronous way, but in fs. readFileSync() method, we can read files in a synchronous way, i.e. we are telling node.
It starts reading the file and simultaneously executes the code. The function will be called once the file has been read meanwhile the 'readFile called' statement is printed then the contents of the file are printed.
The readFile method reads the file indicated by the passed file path, and returns its contents. The path is internally converted by osSafeSpec() . The method assumes that the character of the file are in the default encoding. (The default encoding is set by the Java VM.)
readFile. Returns the contents of the file named filename. If encoding is specified then this function returns a string. Otherwise it returns a buffer.
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.
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.
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.
187
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
