When using node --inspect to profile a NodeJS application using chrome dev tools, a large part of the runtime is spent in (program). I did not find information on what exactly this means? Is it just time spend in the C++ parts of NodeJS?
The (program) entry is Chrome itself - it's the first thing that gets executed before anything else and remains there regardless of what your Node application is doing.
There is discussion in this Chromium profiler issue on what exactly it means (and whether or not it's confusing).
You can also see in the comments of the Changelog for the commit also includes the following comment:
Web Inspector: [Chromium] profiler - differentiate between native code
(program) and idle time https://bugs.webkit.org/show_bug.cgi?id=88446
Reviewed by NOBODY (OOPS!).
Now idleTime is supplied in profile object. In this patch, idleTime,
if any, is subtracted from "(program)" node, and new node "(idle)" is
injected as a top level node ti profile.
Related
I've been going through the documentation at https://bazelbuild.github.io/rules_nodejs/ in order to put together a small web based application. I've got babel building the JS code, and http_server serving it, and ibazel watching it, and everything is working as expected: when I make a change, ibazel notices it and restarts the http_server rule.
The next thing I wanted to look at is getting autoreload in the browser so that the browser would automatically refresh when the change was compiled. My understanding is that this requires the http server to not be killed by ibazel, but instead to stay up and trigger a refresh via the ibazel_live_reload mechanism. I believe that http_server doesn't support this, but ts_devserver is explicitly mentioned in several places. However, ts_devserver doesn't seem to be maintained anymore (although I did find a devserver EXE in the npm package, there isn't a bazel rule that I saw to use it).
Is there a third party live development server that supports the ibazel reload mechanism - or am I missing something completely obvious?
Disclosure, I'm a core maintainer on rules_nodejs
As of rules_nodejs v3.0.0, ts_devserver has been renamed to concatjs_devserver to try and better namespace it (it has little to nothing really to do with Typescript). Its docs can be found here.
Note though that the concatjs_devserver comes with some compatibility gotchas, all dependencies have to be in named AMD/UMD or goog.module format for example, and may be tricky to use unless following the rest of the google3 toolchain.
We've (as the maintainers of rules_nodejs) tried not to wrap an existing devserver and publish it as of yet for various reasons, but it's something that has come up in discussion. I'm currently investigating some options in this space.
I'm not aware of any published devservers that currently support the ibazel protocol, there is a wrap of browsersync in the Angular Components repo which you may find useful.
I am developer with poor experience, however with strong academic CS background.
So please be patient where I am wrong somewhere.
As far I know, typescript can be executed on JS server and it works in this way in my case. Namely, I execute e2e tests with protactor (angular test framework).
I would like to debug it and check what methods was called during such execution on nodejs. To give you more details, I would like if (and possibly parameters) was invoked
waitForAngular(rootSelector, callback) method.
I know that it is possible to dump a variety of traces and debugging info from JVM, however I have no idea how can I do it with nodejs in my specific case.
Could you help me, please?
Around where you have your calls to waitForAngular (or any other code that you want to check), add a console.trace(), which will display a stack trace at that exact line of code.
You can read more about console.trace() and other console API methods at this document by the Chrome project (node.js uses the JS engine that Chrome uses): https://developers.google.com/web/tools/chrome-devtools/console/api#trace
You can sprinkle debugger statements in your code to stop execution which will allow you to step through your code. Similarly, you could start your Node process with the --inspect-brk argument to use Chrome DevTools to step through your code.
There are a lot of questions on this topic, but they don't seem to distinguish between executables for desktop or server-side apps. I suppose my first question would be: what's the difference? For example, Zeit/pkg says they are a "node.js binary compiler", whereas nwjs (formerly node-webkit) says they are a "an app runtime based on Chromium and node.js".
I tried zeit/pkg and it works great, but have read that there can be performance issues unless it's configured properly. I wanted to make sure I was choosing the right tool and came across nwjs. It seems to do a lot of the same stuff pkg does, but has a larger following, as well as more docs and a robust api. Can I use nwjs as a server-side executable (i.e. not using the desktop feature) the same way I would use pkg?
This answer states that nwjs "is an option, but it really isn't set-up to do a server - client type relationship", but then a comment says "you can launch a server from node-webkit just in the way you launch it in Node.js. It's just that node-webkit provide another way beyond B/S architecture".
So, is nwjs effectively the same as pkg, or fundamentally different?
I realize that there's also Electron, which states "build cross platform desktop apps" and appears similar to nwjs. I'm not trying to get into a Electron vs nwjs debate, but rather desktop vs. server, if there's a difference.
you got most things already, only few clarifications are needed. Reason nw.js / Electron declares itself as for desktop application is, it's core architectural design is intended to integrate node.js with chromium to have UI enables create application does have UI. You can still use part of those framework (node.js side) without initiating visible ui, in that case behaviorwise it'll be similar to plain node.js does. Still there is caveat, like as it tightly integrated with chromium in core already for some cases you should have screen to chromium correctly initiates (or creating virtual buffer as lot of CI does, or etcs).
Also, when your concern is performance, I'd doubt using UI framework for server side work achieves what you desire - while there won't be huge, integration between node to chromium have overhead compare to bare node.js obvioulsy.
Getting back to original question, I feel question itself is somewhat vague. If the intention is truly server side application probably you won't need to package it but correctly deploy node and its dependency modules or packaging it sort of installable manner instead of creating single binary as pkg does.
So, here's the situation. I've recently "inherited" a decent sized web application, built using React (and Redux) and compiled using webpack/babel. Two files are generated, app.js and server.js, both of which run on Node.
The original developer of the project was mostly "winging it" on the back-end (server.jsx and so on -> server.js), using console.log to figure out what was going on, and then just gut feeling the fix. That works on a smaller scale, but will be problematic in time.
I can debug both of the actual files, but only app.js is ever mapped properly, meaning I can debug the source code. This also affects hot loading. Any breakpoints related to server.js will only trigger in the actual server.js file in IntelliJ, which is a completely unreadable mesh, so that's not really an option.
I'm using IntelliJ (WebStorm for those of you who only use the web version), and I've tried to use every single guide I've come across to set it up, which usually comes down to babel-node, babel watchers or webpack-dev-server. The current app.js is run using webpack-dev-middleware, and debugging it in Chrome works like a charm, but for some reason it always just bundles in server.js and then fires when ready (in these Star Wars times).
I understand that it's hard for Chrome to get access to server.jsx, but surely there must be some way of setting up IntelliJ (or WebStorm) to do so? I'm more used to a Java or C# server side, so I'm a bit baffled that this isn't a straight forward, out-of-the-box option. Or maybe it is, and the initial setup is lacking?
PS. When using React (and Redux) as both the front and back end on Node, is it meant to be virtually impossible to distinguish between the two? Server.jsx is fairly obvious, but there are quite a few duplicated javascript files and dependancies, especially related to handling/building the Redux store.
I don't want to use services like nodetime. I have small middleware nodejs application. And now I my application use cpu in strange way http://s27.postimg.org/fgzmmh85f/cpu.png So I need simple tools to profile my code. I tried to use node --prof app.js but Chrome Dev Tool doen't open generated log-file.
Please advise tool to find out bottlenecks. Also I can't understand how v8 garbidge collector works.
I'm not node expert, but I've been trying to profile some JS code for some time now. This is what I can tell you:
There are two ways to profile, but both provide the same data. The first one is running your code with node --, which will generate an isolate*.log file. You give this file to node --prof-process and this will give you smoe output that, if you're kinda lucky, you can understand and act upon.
The second one is more or less like this:
var profiler = require('v8-profiler');
profiler.startProfiling('carto');
[your code here]
var profile = profiler.stopProfiling('carto');
profile.export(function(error, result) {
fs.writeFileSync('carto.cpuprofile', result);
profile.delete();
})
This will generate a .cpuprofile that you can load in chromium's JS Profiler. This can be found in the Developer Tools, and you will have probably to enable the Javascript Profiler in the More Tools menu. This will give you three different ways to see in which functions you're spending time.