Over the past few years, Neo4j has become the standard for efficiently modeling graph-based data.

In addition, the use of Node.js in building flexible service infrastructures on top of Neo4j graph databases and serving the necessary HTML and static resources enables developers to build great applications.

As with other technologies, the data model and service design predetermines how well your application performs in production. But, what if you’re already running your application in production and you realize that in some cases it’s running slowly?

If your application consists of dozens of different service calls spread over a multitude of HTML and asynchronous JavaScript elements, then such performance bottlenecks are tremendously difficult to find.

In this post, I’ll explain how to monitor a sample Node.js application using an underlying graph data model residing in a Neo4j database in real time.

An Example of Neo4j Application Performance Monitoring

As a first step, we’ll automatically discover the service dependencies within your application. Following that, we’ll be able to monitor the load of each of your services and the response times of your application and service requests.

Our sample application visualizes the topology of applications, as shown in the following Neo4j Cypher query.

To visualize this graph within our Node.js application for a public audience, we defined several services (apprelations, hostrelations, and apps) that return the application and host nodes in the form of JSON payloads.

The example imports the express framework that serves the static content, such as an HTML page called appgraph.html which visualizes the result using JavaScript.

var neo4j = require('node-neo4j');
var express = require('express');
var app = express();

app.use(express.static('public'));

app.get('/apprelations', function (req, res) {
db = new neo4j('http://127.0.0.1:7474');
db.cypherQuery("MATCH (n:APPLICATION)-[r]-b RETURN n,b", function(err, result){
if(err) throw err;
// some processing
var rdata = { 'nodes': nodes, 'edges': edges};
res.send(rdata);
});
});

app.get('/hostrelations', function (req, res) {
db = new neo4j('http://127.0.0.1:7474');
db.cypherQuery("MATCH (n:HOST)-[r]-b RETURN n,b", function(err, result){
if(err) throw err;
// some processing
var rdata = { 'nodes': nodes, 'edges': edges};
res.send(rdata);
});
});

app.get('/apps', function (req, res) {
db = new neo4j('http://127.0.0.1:7474');
db.cypherQuery("MATCH (n:APPLICATION) RETURN n", function(err, result){
if(err) throw err;
// some processing
var rdata = { 'nodes': nodes, 'edges': []};
res.send(rdata);
});
});

var server = app.listen(8080, function () {
  var host = server.address().address;
  var port = server.address().port;
  console.log('Example app listening at http://%s:%s', host, port);
});

The running application visualizes the graph within a simple HTML/JavaScript page, as shown below:

How Ruxit Helps You Monitor Application Performance

To monitor the operation of the sample application we installed Ruxit Agent on the host and logged into Ruxit to investigate the auto-detected service and application topology in the smartscape view.

Ruxit Agent immediately detected requests to the application’s webpage and visualized the service communication of both the built-in Neo4j browser UI requests and the users’ requests to the appgraph.html page.

The topology shows that Neo4j exposes seven database services, while our Node.js application services are shown as the blue topology path on the right side.

After reviewing the topology of the newly created application, it’s interesting to see the traffic the application page gets from real users and how the traffic affects the load and performance of the Node.js services.

A click on the application node in Smartscape shows that the application page has steady traffic of about 40 requests per minute between 17:30 and 18:45 and that the median response time is around 1 second.

Ruxit shows that the application depends on eight individual services (see below).

This service page for the Node.js application offers an overview of the performance and error rates of the Node.js services. On the right side, you see the top response-time consumers in the Node.js application. These top consumers are likely to influence the overall performance of your application.

A click on the most time-consuming service (/hostrelations) reveals detailed statistics related to response times and error rates.

By reviewing this detailed service method chart it’s easy to see that at 18:40 the service had a load of 43.5 requests per minute and that it responded with a median performance of 23 ms.

Neo4j performance analysis doesn’t end here. The Ruxit services page gives you insights into where to look for bottlenecks within your Neo4j application.

Conclusion

Combining numerous services to build highly dynamic Node.js applications with Neo4j presents a great opportunity for developers.

And, monitoring and reviewing service dependencies and performance is a crucial factor in building reactive applications that provide high usability standards.

Using next-generation full-stack performance monitoring solutions like Ruxit help you keep an eye on application performance and service dependencies in real time. 

This article was written by Wolfgang Beer (Technical Product Manager, Ruxit)