Troubleshooting the Performance of Vert.x Applications, Part III — Troubleshooting Event Loop Delays

This article was originally published on Ales Nosek – The Software Practitioner.

In the previous entry to this series, we reviewed several techniques that help you to prevent event loop delays. However, even the best programmer makes mistakes. What should you do when your Vert.x application doesn’t perform as expected? How to find out what part of your code is blocking the event loop threads? In the final part of the series, we are going to focus on troubleshooting event loop delays.

The event loop thread model is vastly different from the thread-per-request model employed by standard JEE or Spring frameworks. From my experience I can report that it takes developers some time to wrap their heads around it and that at the beginning they tend to make the mistake of introducing blocking calls into the event loop’s code path. In the following sections, we will discuss several techniques of how to troubleshoot such situations.

Continue reading “Troubleshooting the Performance of Vert.x Applications, Part III — Troubleshooting Event Loop Delays”

Troubleshooting the Performance of Vert.x Applications, Part II — Preventing Event Loop Delays

This article was originally published on Ales Nosek – The Software Practitioner.

In the previous part of the series, we took a closer look at the event loop model. In this article, we are going to discuss several techniques that help you to prevent event loop delays.

The causes of event loop delays can be divided into two categories. The first category contains event loop delays caused by a handler calling a blocking API. The second category covers delays caused by a handler code taking a great amount of CPU time to complete. Let’s start with the first category and talk about blocking API calls.

Continue reading “Troubleshooting the Performance of Vert.x Applications, Part II — Preventing Event Loop Delays”

Walk the Walls with Red Hat Open Innovation Labs

Troubleshooting the Performance of Vert.x Applications, Part I — The Event Loop Model

This article is the first in a series of three articles which share my experience with troubleshooting the performance of Vert.x applications. The first article, originally posted on Ales Nosek – The Software Practitioner, provides an overview of the Vert.x event loop model, the second article covers techniques to prevent delays on the event loop, and the third article focuses on troubleshooting of event loop delays.

Programming with Vert.x requires a good understanding of its event loop model. From what I saw in practice, delayed or blocked event loop threads are the number one contributor to performance problems with Vert.x applications. But don’t worry. In this article, we are going to review the event loop model.

Continue reading “Troubleshooting the Performance of Vert.x Applications, Part I — The Event Loop Model”

How to use Everything as Code to create a shared language between Product and Platform teams driven by Ansible Tower and Self Service models

 

Disclaimer: the high-level architecture solution and the related demo code is an opinionated implementation to solve the problem described here. The author believes that DevOps is not about tools and frameworks, but a mindset and cultural change for teams. This is an implementation that aims to help a team on the DevOps journey of increasing shared understanding within traditional Development and Operation teams.

 

There are some challenges while adopting a PaaS Platform like OpenShift in an organization. Traditional IT teams have operated in silos where responsibilities for different parts of the Product lifecycle were distributed to different teams, for example, a development team and a release or production team. The teams’ domain of knowledge is, traditionally, limited to the activities they perform for their part of the chain of work and communication between these teams lacked flow or was done using ticketing systems that increase handoffs.

Continue reading “How to use Everything as Code to create a shared language between Product and Platform teams driven by Ansible Tower and Self Service models”