How to Monitor Neo4j-Based Application Performance with Ruxit [Community Post]


[As community content, this post reflects the views and opinions of the particular author and does not necessarily reflect the official stance of Neo4j.]

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.

topology-neo4j-applications


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('https://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('https://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('https://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 https://%s:%s', host, port);
});

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

graph-of-javascript


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.

node-js-topology-path


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.

application-performance-smartscape


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.

Learn How Ruxit Helps You with Application Performance Monitoring with Neo4j Apps


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.

application-service-method-chart


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

neo4j-application-bottlenecks


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.


Ready to build your first app with Neo4j? Get your free copy of the Learning Neo4j ebook and build your app on top of the world’s leading graph database.