I am working on using WebAssembly in Node.js (Netlify Functions, which internally uses AWS Lambda).
The problem is that it takes as long as 24s for WebAssembly.instantiate to finish.
The size of the .wasm file is about 9MB. It is a sheet music library called webmscore (https://github.com/LibreScore/webmscore).
I also tried separating WebAssembly.instantiate into two steps: WebAssembly.compile to compile module and WebAssembly.instantiate to instantiate the module. In this case, compile takes 24s, while instantiate finishes very quickly.
In the local environment (Node in Windows 10), WebAssembly.instantiate takes about 5s. In the client side (Chrome browser), it takes less than 1s. So, I expected it to finish soon in the deployed Node.js environment as well, but it doesn't. Is it normal for the instantiation to take a longer time in deployed Node.js than in other environments? Is there any way to make it faster?
Related
Are functions created as a web app slower on first load than a regular function?
I have a HttpTrigger as a normal function (in a .csx), and one in a web app. And it feels like the first response is slow on the web app one. Subsequent calls are fine. Feels like the first one just woke it up.
In a normal function I haven't really experienced that
Assuming by function in a web app, you're referring to the pre-compiled model using a web app project, please correct me if I'm wrong.
Cold start performance will be better when using the pre-compiled model (as there is no need for a compilation step). What you may be observing as a comparison between cold start (for the web app based version) and a warm host (for the CSX), as changes to your CSX will not trigger a host reload, just a recompilation of your function, where redeploying a pre-compiled function does.
If you restart both sites and compare first request performance, you should see a better results with the pre-compiled version (those may be variable and will be more noticeable if you have a larger number of functions)
I'm running electron on linux server for web scraping. And currently I'm running new electron command for each task. But it results in high cpu usage. Now thinking about running single electron instance, and create new BrowserWindow for each task. It will take some time to adapt the code base for this style, so I wanted to ask here first. Will it make a difference in cpu usage, and how much?
Basically, creating a new NodeJS process will result in re-parsing your application's code, which will highly affect your CPU usage. Creating only a new BrowserWindow will only create a new renderer process, which is way more efficient.
If your application is packaged, e.g. with electron-packager, then creating a new instance will also affect your CPU usage like creating another NodeJS process, because that packaged (aka compiled) application has a copy of NodeJS in it, which is enough to run your code, but still affects the CPU usage.
But the decision depends on how you use the server. If you only run the Electron application to carry out the tasks that have been defined by you, adapting your working code would have no to only a low benefit. If you want to release this application and/or that server is used by some other tasks, e.g. a web server, it would be a real benefit if you adapt your code.
Running multiple instances of the main nodejs process with the default configuration is not actually supported or tested. You'll find that any features that persists data to disk either don't work, or don't work as expected (ie. localstorage, indexeddb, sessions, etc).
https://github.com/electron/electron/issues/2493
You can work around this by changing the data directory for each instance so they don't trample over each other but this is likely to use a lot of disk space and you'd need a way to keep track of all these data directories.
A single main process with multiple renderers is nearly always the answer.
I have an Azure Function app in Node.js with a couple of Queue-triggered functions.
These were working great, until I saw a couple of timeouts in my function logs.
From that point, none of my triggered functions are actually doing anything. They just keep timing out even before executing the first line of code, which is a context.log()-statement to show the execution time.
What could be the cause of this?
Check your functions storage account in the azure portal, you'll likely see very high activity for files monitoring.
This is likely due to the interaction between Azure Files and requiring a large node_modules tree. Once the modules have been required once, functions will execute quickly because modules are cached, but these timeouts can throw the function app into a timeout -> restart loop.
There's a lot of discussion on this, along with one possible improvement (using webpack on server side modules) here.
Other possibilities:
decrease number of node modules if possible
move to dedicated instead of consumption plan (it runs on a different file system which has better performance)
use C# or F#, which don't suffer from these limitations
Using Node.js, how can I compute the time since the current process (the one running node) was started?
Ideally I'd like a cross-platform solution but a macOS-only solution would also be okay.
Unfortunately it is impossible for me to inject any code into Node.js startup. My library will only be loaded at some unknown point after the process starts.
The function process.uptime() (available since v0.5.0) returns the number of seconds the current Node.js process has been running. I don't have a Mac to check, but there's no caveat in the documentation that it only works on certain platforms.
My node application currently has two main modules:
a scraper module
an express server
The former is very server intensive task which indefinately runs in a loop. It scrapes information from over more than 100 urls, crunches the data and puts it into a mongodb database (using mongoose). This process runs over and over and over. :P
The latter part, my express server, responds to http/socket get requests and returns the crunched data which was written to the db by the scraper to the requesting client.
I'd like to optimize the performance of my server so that the express requests and responds get prioritized over the server intensive task(s). A client should be able to get the requested data asap, without having the scraper eat up all of my server resources.
I though about putting the server intensive task or the express server into its own thread, but then I stumbled upon cluster, and child processes; and now I'm totally confused which approach would be the right one for my situation.
One of the benefits I'm having is that there is a clear seperation between the writing part of my application and the reading part. The scraper writes stuff to the db, express reads from the db (no post/put/delete/...) calls are exposed. So, I -guess- I won't run into threading problems with different threads trying to write to the same db.
Any good suggestions? Thanks in advance!
Resources like cpu and memory required by processes are managed by the operative system. You should not waste your time writing that logic within your source code.
I think you should look at the problem from outside your source code files. Once they ran they are processes. Processes are managed, as I said, by the OS.
Firstly I would split that on two separate commands.
One being the scraper module (eg npm run scraper, that runs something like node scraper.js).
The other one being your express server (eg npm start, that runs something like node server.js).
This approach will let you configure that within your OS or your cluster.
A rapid approach for that will be to use docker.
With two docker containers running your projects with cpu usage limitations. This is fairly easy to do and does not require for you to lift a new server... and at the same time it provides the
isolation level you need to scale it to many servers in the future.
Steps to do this:
Learn a little about docker and docker compose and install them in your server
Build a docker image for your application (you can upload it to a free private image that docker hub gives you for free)
Build a docker compose for your two services using that image, with the cpu configuration you need (you can set both cpu and memory limits easily)
An alternative to that would be running the two commands (npm run scraper and npm start) with some tool like cpulimit, nice/niceness and ionice, or something else like namespaces and cgroups manually (but docker does that for you).
PD: Also, I would recommend to rethink your backend process. Maybe it's better to run it every 12 hours or something like that, instead of all the time, and you may run it from within cron instead of a loop.