[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.
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:
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 theappgraph.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.
/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.
