The NEW API Pattern

Distributed Architectures are a lot like neural networks; all services that talk to each other need to share the I/O in and in a way that they can synchronize that information on the fly. The way the brain does is that each neuron that communicates with another has the other neuron fire back a neurotransmitter to synchronize and improve that communication in the future thus creating a pattern.

While this behavior is almost identical to what is known as a webhook in the API world, we do not follow the same principles for API design in distributed architectures. Since the API Pattern designed in the 1970’s for centralized architectures and NOT distributed architectures, it was never intended to be used in this way and creates an architectural cross-cutting concern when used in distributed services.

Continue reading “The NEW API Pattern”

Share

Using New Relic in Red Hat Mobile Node.js Applications

Introduction

New Relic is an application-monitoring platform that provides in-depth analytics and analysis for applications regardless of the type of environment where they are deployed, or as New Relic put it themselves:

“Gain end-to-end visibility across your customer experience, application performance, and dynamic infrastructure with the New Relic Digital Intelligence Platform.” – New Relic

You might ask why there’s a use for New Relic’s monitoring capabilities when Red Hat Mobile Application Platform (RHMAP) and OpenShift Container Platform both offer insights into the CPU, Disk, Memory, and general resource utilization of your server-side applications. While these generic resource reports are valuable, they might not offer the detail required to debug a specific issue. Since New Relic is built as an analytics platform from the ground up it is capable of providing unique insights into the specific runtime of your applications. For example, the JavaScript code deployed in Node.js applications is run using the V8 JavaScript engine which has a life-cycle that can have a significant impact on the performance of your application depending on how you’ve written it. Utilizing New Relic’s Node.js module provides a real-time view of V8 engine performance and how they might be affecting the performance of your production application. By using this data, you can refine your application code to reduce memory usage, which in turn can free CPU resources due to less frequent garbage collections. Neat!

Continue reading “Using New Relic in Red Hat Mobile Node.js Applications”

Share

Profiling NodeJS applications with Linux Performance Tools

Using Linux Perf Tools

The Performance Analysis Tool for Linux (perfis a powerful tool to profile applications. It works by using a mix of hardware counters (is fast) and software counters, all provided by the Linux Performance Counter (LPC) subsystem that takes charge of the complex task of wrapping the CPU counters for the different type of CPUs. So you can have access to a very efficient way to get information of running processes through their C API or a convenient command in this case (perf).

This command gives you access to a great variety of system and process level events but in this entry, I will use it to investigate CPU bounded issues.  

Continue reading “Profiling NodeJS applications with Linux Performance Tools”

Share

Running HPC workloads across multiple architectures with Red Hat Enterprise Linux

In this article, I want to provide some background details about our recently developed demonstration video – “Running Game of Life across multiple architectures with Red Hat Enterprise Linux“.

This video shows the Game of Life running in a heterogeneous environment using three 64-bit hardware architectures: aarch64 (ARM v8-A), ppc64le (IBM Power little endian) and x86_64 (Intel Xeon). If you are not familiar with the rules of this cellular automaton, they are worth checking out via the reference above.

Continue reading “Running HPC workloads across multiple architectures with Red Hat Enterprise Linux”

Share

The need for speed and the kernel datapath – recent improvements in UDP packets processing

Networking hardware is becoming crazily fast, 10Gbs NICs are entry-level for server h/w, 100Gbs cards are increasingly popular and 200Gbs are already surfacing. While the Linux kernel is striving to cope with such speeds with large packets and all kind of aggregation, ISPs are requesting much more demanding workload with NFV and line rate packet processing even for 64 bytes packets.

Is everything lost and are we all doomed to rely on some kernel bypass solution? Possibly, but let’s first inspect what is really the current status for packet processing in the kernel data path, with a perspective look at the relevant history and the recent improvements.

We will focus on UDP packets reception: UDP flood is a common tool to stress the networking stack allowing arbitrary small packets and defeating packet aggregation (GRO), in place for other protocols.

Continue reading “The need for speed and the kernel datapath – recent improvements in UDP packets processing”

Share

Scaling Sync

Introduction

One of the biggest challenges for developers to build mobile applications is data synchronization. It’s the foundation for many different types of mobile applications, but it’s very complicated and very hard to implement.

Continue reading “Scaling Sync”

Share