Written by James Butcher, EdgeX Foundry Core Working Group Chair and Edge Xpert Product Manager at IOTech Systems
Following the recent release of EdgeX Foundry version 2.1, codenamed “Jakarta”, I thought it would be useful to provide a quick update on some of the performance metrics of the platform as it has evolved over the last couple of release cycles.
This release of EdgeX is also the first long-term support (LTS) edition, whereby the EdgeX community will support this version with critical fixes for major flaws or bugs. The project’s detailed testing strategy helps to provide the confidence that this version is robust and reliable - and is key to the community making those LTS statements. See here for more details about the LTS policy.
Recent EdgeX Working Group Changes
You may know that the EdgeX QA & Test Working Group was previously responsible for the creation and operation of the community’s testing strategy and its main Test Automation Framework (TAF). This summer, the QA & Test group was merged into the EdgeX Core Working group, and I was pleased to be given the opportunity to chair the new combined group.
A key part of the EdgeX Core Working Group is its commitment to testing which helps ensure the quality and robustness of the framework. An EdgeX version is only released, for example, when all key requirements are reliably tested and preferably automated as part of TAF.
EdgeX Performance Metrics
Another key part of the EdgeX testing strategy is the recording and monitoring of performance metrics. Since EdgeX 1.1 (Fuji), we have been running dedicated performance tests with each release and producing formal performance reports that describe the findings.
I mentioned some of the performance testing advancements in my blog around the release of EdgeX 1.3 (Hanoi). We cover key points such as footprint, CPU usage and latency of data flow through the platform.
In the last couple of cycles (Ireland and Jakarta) we are now also recording performance related to running with the EdgeX Security Services.
Please find the Jakarta Performance Report here or click on the image below.
The data continues to show that the EdgeX microservices developed by the community are generally pretty small and lightweight. One of the EdgeX Core Services, Core Metadata, for example, has a Docker image footprint of around 17MB.
Some of the third-party services we bring in, such as the Security Services or the Registry Service are a little larger, but still the footprint of the complete EdgeX stack requires less than 1GB of disk space. Note also the microservices architecture means not all services need to be deployed in all scenarios. It’s easy to pick and choose the services needed for each use case or physical hardware capability.
So whilst quite lightweight, we are still pushing for EdgeX to be smaller and faster where possible. The next couple of EdgeX development cycles (Kamakura and Levski) are devoting time to this, but a nice reduction in Jakarta is a drop in the run-time memory usage for the API Gateway Security Service. In previous EdgeX versions, memory consumption of the complete stack was recorded as around 1GB RAM, but an optimization such as configuring the API Gateway Service to run with a specific number of worker processes, means we can be much lower than that when needed. These types of config options are invaluable in helping to tune the framework, if physical resources are a concern.
Full Commercial Support and Value Add
I also wanted to mention IOTech’s commercially supported edition of EdgeX, named Edge Xpert. Edge Xpert 2.1, based on EdgeX Jakarta, will be available very soon so stay tuned for more info. Head to the IOTech website to understand how Edge Xpert features and its technical support offerings can help users deploy the EdgeX based technology more easily.
Open Community
Finally, please feel free the join our EdgeX Core meetings where we discuss progress and other issues that need to be addressed each week. We meet every Thursday at 8am PST. You can find the meeting links on our page here.