Foreword
One of the stumbling blocks in the development of node.js is more difficult, compared to other modern languages, debugging. Due to the asynchronous structure of the code in a large application, it is difficult to find a memory leak or a place of intensive use of the processor without specialized utilities. At different times for node.js, profiling tools have already been created, but most of them are either simply not convenient enough or are no longer supported by developers.
Search
For a long time, I managed with conservative debugging methods in the form of periodic output of the amount of memory used and the execution time of critical sections of code to the console, but the moment came when the need for a high-quality tool became very urgent.
First of all, I decided to see if the
node-inspector had recovered, which, after switching to node.js 0.6.x, stopped supporting the profiling of CPU and Heap. It turned out that in the new version of node-inspector, the broken profiling was finally eliminated and now it's just a debugger. Having a little rummaged in the code of the old version, I nevertheless managed to get profiling of CPU and Heap on node 0.8.x, however this solution was not ideal. To get it out of the “crafts” state, it would be necessary to replace the outdated WebKit console interface with a modern one, rewrite a decent amount of code and fix some performance problems. In general, the solution based on the WebKit console seems to me very not flexible, so I threw this idea and continued the search.
')
Here it is
After trying a few different options, I came across the
https://nodetime.com service. This is a tool of a completely different level, which is much more than others suited to the role of “that very” ideal instrument. The service consists of two parts:
- backend - collects detailed statistics on the application;
- frontend is the service itself, which displays this statistics in a form that is understandable to humans.
In addition to the most necessary tools for profiling CPU and Heap, nodetime contains a set of metrics that greatly simplify development. Very pleased with the simplicity and accessibility of the service. To get started, simply connect the nodetime module to the project.
In addition to collecting and displaying statistics in real time, nodetime provides the ability to save and view statistics for certain periods of time, as well as to set up notifications for certain events (for example: a memory leak).
I want more
Of course, the nodetime service is very convenient, but there is not always the possibility of remote debugging of the application. For many, the issue of confidentiality of data collected by the profiler is very acute, and the ability to debug without a network connection is not at all superfluous.
Because The backend nodetime is distributed under the MIT license, for which many thanks to
its author , I decided to create an interface based on it that could be used locally. Having spent a week and a half of free evenings to parse the protocol and implement the interface, I got a stable version, which is not a shame to show people. Meet ...
Look
To start the demo:
Here is an
example of the implementation of the chat .
And here you can look at the work profiler.
Warning: the demo is running on a weak VPS, a big request not to make a hardcore so that everyone can watch.
The source code for the project
is located on GitHub . You can add a module to your application using
npm .
npm install look
For the module to work, it is enough to connect it to the application and, if desired, specify the port and interface on which the profiler will work. By default, the profiler runs on port 5959 and listens to the interface '0.0.0.0'.
A simple example:
require('look').start(3131); var http = require('http'); http.createServer(function (req, res) { res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World\n'); }).listen(8080, '0.0.0.0'); console.log('Server running at http://0.0.0.0:8080/');
After starting the application, the profiler will be available on port 3131 of your server.
The interface is managed by a small
connect- based application that runs in a separate thread so as not to affect the operation of the main application.
Conclusion
This is the first stable look version that implements the most essential functionality. As needed, look will improve, there is room to grow. I hope this tool helps you write your node.js applications better.