Suppose I have a node.js cli program that can be run as node some-program.js and it exits in 10 seconds. How do I profile it? I want to get flame graphs and time spent in each functions.
node --prof some-program.js will produce an isolate-* for each worker thread.
node --prof-process isolate... will produce a user-friendly output.
You need some experience to be able to read it - but basically your program spends time in three ways: executing JS code, compiling JS code and running system libraries.
Related
While I don't suppose that there are any processes for node.js on my windows computer, but there are two node.js processes that I can see on task manager.
I don't mean to run any node.js right now. But I have two node.js processes like above.
I had run node.js process by pm2 module before, so it affects badly maybe.
Is it ok to kill the two processes manually from task manager? Or, either process has any other purposes than executing program I wrote, so I should keep either of them or both?
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.
I have a Node.js/Express web application which sometimes slow response. After checked the system CPU and memory I found it consumed ~80% CPU and memory, and then 1 - 2 minutes later they down to ~10%.
I think this was because my Node.js is running some codes in user-thread, for example mapping objects retrieved from database.
It's a little bit hard to review the code of my application to figure out where the bad code was. So I would like to know is there any tool or npm module I can use to write down the code Node.js is running when an API request was processed longer than, for example 5 seconds.
I tried v8-profiler but it seems that it only support to start profiling and then stop, but not capture what code is running at that moment.
use visual studio code for debuging your nodejs code
https://code.visualstudio.com/b?utm_expid=101350005-24.YOq70TI1QcW9kAbMwmhePg.1&utm_referrer=https%3A%2F%2Fwww.google.com.pk%2F
We use clustering with our express apps on multi cpu boxes. Works well, we get the maximum use out of AWS linux servers.
We inherited an app we are fixing up. It's unusual in that it has two processes. It has an Express API portion, to take incoming requests. But the process that acts on those requests can run for several minutes, so it was build as a seperate background process, node calling python and maya.
Originally the two were tightly coupled, with the python script called by the request to upload the data. But this of course was suboptimal, as it would leave the client waiting for a response for the time it took to run, so it was rewritten as a background process that runs in a loop, checking for new uploads, and processing them sequentially.
So my question is this: if we have this separate node process running in the background, and we run clusters which starts up a process for each CPU, how is that going to work? Are we not going to get two node processes competing for the same CPU. We were getting a bit of weird behaviour and crashing yesterday, without a lot of error messages, (god I love node), so it's bit concerning. I'm assuming Linux will just swap the processes in and out as they are being used. But I wonder if it will be problematic, and I also wonder about someone getting their web session swapped out for several minutes while the longer running process runs.
The smart thing to do would be to rewrite this to run on two different servers, but the files that maya uses/creates are on the server's file system, and we were not given the budget to rebuild the way we should. So, we're stuck with this architecture for now.
Any thoughts now possible problems and how to avoid them would be appreciated.
From an overall architecture prospective, spawning 1 nodejs per core is a great way to go. You have a lot of interdependencies though, the nodejs processes are calling maya which may use mulitple threads (keep that in mind).
The part that is concerning to me is your random crashes and your "process that runs in a loop". If that process is just checking the file system you probably have a race condition where the nodejs processes are competing to work on the same input/output files.
In theory, 1 nodejs process per core will work great and should help to utilize all your CPU usage. Linux always swaps the processes in and out so that is not an issue. You could start multiple nodejs per core and still not have an issue.
One last note, be sure to keep an eye on your memory usage, several linux distributions on EC2 do not have a swap file enabled by default, running out of memory can be another silent app killer, best to add a swap file in case you run into memory issues.
I'm writing a trajectory predictor in Node.JS. You may think it's a funny language to write one in, but it's actually working great. Now, I want to be able to start the predictor from a web interface in Node.JS.
The actual predictor process takes about 5 minutes to run. So to spawn it from the Node web process, I don't want the web process waiting for the child process to finish. What is the best method of forking, in Node.JS, to allow for spawning and releasing a process like this?
Use the built-in child_process node module: http://nodejs.org/api/child_process.html