Over a million developers have joined DZone.

Making Sense of Spaghetti Transactions

DZone's Guide to

Making Sense of Spaghetti Transactions

Free Resource

Today’s modern applications are built from an ever growing number of moving parts (e.g. queues, caches, services connecting different application tiers, and outgoing calls to external services). These parts are also dynamic—layers grow or shrink to scale, are load balanced, and since they are virtual or in the cloud, they can also physically move quickly. Transactions can literally pass through hundreds of different paths in your average application. These are spaghetti transactions.

Every piece of spaghetti has a start and an end, but how each one passes is difficult to see when it’s in a pile. Understanding spaghetti transactions, and how they flow between all the parts of the application’s topology has become more time consuming than ever.

Efficient management of these applications requires a new approach – moving from individually managing the health of each server, operating system, and the workload it runs, to managing applications and multi-tier transactions.

This is the motivation that VMware had to build vFabric AppInsight. With it, admins can instantly see through the spaghetti to find the full topology of the application transactions across tiers, and easily perform a root cause analysis (RCA) of performance problems in your application by pointing out the specific, problematic call.

Modeling Transactions

vFabric AppInsight automatically models multitier transactions across all servers, components, and method calls involved in its execution. Simplified visualizations help app owners to separate the transaction paths from a pile of spaghetti to an organized, easy to follow visualization. To illustrate, let’s take a look at three examples covering both synchronous and asynchronous calls as well as calls to external resources on the web.

Synchronous calls

Let’s take a simple example where a business transaction requesting a hotel availability for a night involves a web server, application server and a database. The components are mapped as follows:

AppInsight identifies these 3 servers, and the transaction will be displayed from the method that processed the URL request in the web server, through the method called in the application server, and up to the database query it generated against the database.

Here is a view of the transactions across tiers:

We can see that “httpsenderservlet” method in the web server is calling 3 methods in our application server, and only two of them are actually calling the database (“HotelsController#list” and “HotelsController#search”). Why is AbstractController#handleRequest not calling anything? [Zvika] It just does some logic in memory and doesn’t keep anything in the database.

Asynchronous calls

vFabric AppInsight supports also asynchronous transactions, i.e. transactions that use messaging technologies such as JMS, AMQP, etc. In this example, the vFabric Reference Application NanoTrader is monitored. The components found for this application are shown below:

And here is one of the transactions:

Here, we’ve highlighted the flow of DirectChannel#toJsonChannel transaction. This transaction is calling a RabbitMQ server. A cluster of 2 servers is consuming the message from the queue, and then continue processing it by calling a database, and calling another queue. We can easily understand the flow, the timing and assess that all components in this transaction are available and running within acceptable parameters. If there were to be a problem, we could see a change in the hits/minute or latency that would quickly identify where the problem is starting.

External calls

Even if the application transaction involves other components which are not monitored by AppInsight agents, such as LDAP, we will show them as components in the application topology. We support several types of components without AppInsight agents such as: Databases, Queues, LDAP, Cache, Web Services, etc.

In this example, our application is just using the Google finance service. vFabric AppInsight shows how much time was spent on the calling war and on the external service used.

How is Transaction Tracing Done?

Each agent tags its outgoing requests (e.g. in http it adds an ID to the header of the call). It also sends a message to the AppInsight server saying for example: “agent1” with transaction “#login” sends “ID2” to server “orders_server” with monitoring data.

Then, the AppInsight server gets all these messages from all of the agents and builds the transaction from the root. IDs are also passed when calling queues, making it possible to build asynchronous transactions.

The data transferred between the application components and the AppInsight server is minimal. Transaction data is based on sampling, meaning it is not collected for all of the transactions, but just for a configured percentage of the calls. This means that your performance data is statistically relevant, and based off of real user interactions. It also minimizes the performance impact of collecting the data by not tracking every transaction or creating a whole new set of synthetic transactions.

For more detail on how vFabric AppInsight, a component of vFabric Application Performance Manager, can help you to visualize your transactions:

About the Author: Zvika Idelsberg has over 9 years of experience in software engineering.  He is part of the vFabric AppInsight R&D for almost 1.5 years, and at VMware since 2010. Prior to joining VMware, Zvika worked at SAP in a product jointly developed by SAP and Microsoft. He holds a B.A in Computer Science from the Interdisciplinary Center Herzliya, and an MBA from Bar-Ilan University.

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}