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”
We want to give you the opportunity to weigh-in on some exclusive new Red Hat Training content!
Continue reading “Impact the future of Red Hat Training Video Classroom”
In this blog post, originally posted on Ales Nosek – The Software Practitioner, I am going to talk about how I installed OpenShift 4.1 on a Fedora laptop with 16 GB of RAM. If you are interested in deploying your own OpenShift instance whether for evaluation or testing please follow along with me.
Continue reading “Installing OpenShift 4.1 Using Libvirt and KVM”
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”
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”
This post was originally published on the ETI blog here.
So – you want to stop your OpenShift cluster? There are many reasons why you may want to stop your OpenShift cluster. Maybe you have an annual disaster recovery test where you shut down a whole datacenter. Perhaps you want to do some maintenance to your infrastructure or the hypervisor or storage that your cluster is hosted on. It’s not an uncommon to need to be able to do this, so I have collated some of the best practices I have experienced across a multitude of environments, both large and small.
Here is the process that I recommend to use as a best practice in order to stop and start your OpenShift cluster(s). Following this process will give you the best chance of a trouble free maintenance window. As with all things, you should exercise care with this process on your important clusters. Try it on an unimportant environment first and see if it is a good fit for you.
Important: This process will cause an outage to any application workload running on the cluster until the cluster is fully started. The cluster itself will be unavailable until manually started. Care should be taken to run this process only on appropriate environments. It is recommended to have backups available of your environment.
Continue reading “How To: Stop and start a production OpenShift Cluster”