With version 26.0.0, we introduced a powerful new feature: application-specific logging. It is available for Business Automation Workflow and Workflow Process Service in IBM Cloud Pak for Business Automation, as well as for IBM Business Automation Workflow (traditional and on containers). This enhancement allows each process application or workflow automation to write log messages to dedicated log files, separate from the default log files such as SystemOut.log.
Besides the obvious operational benefits for governance and debugging, the new mechanism also significantly improves JavaScript logging performance. This improvement can ultimately have a positive impact on overall process throughput for applications that rely heavily on logging.
To show this, we conducted performance tests to validate this feature's behavior in multi-user, multi-application scenarios.
Scenarios and goals
The new logging capability provides flexibility in how JavaScript log messages are captured, as n Process Applications can write into 1-n separate files. We focused on measuring these three straightforward scenarios:
- Scenario 1: Baseline: Continue using the default SystemOut.log.
- Scenario 2: All Process Applications write to a single global custom log file.
- Scenario 3: Separate application-specific log files. One file per Process Application.
Our testing focused on answering these key questions:
- How does performance compare between the scenarios?
- What is the CPU impact across different scenarios?
- Are there any bottlenecks in multi-user, multi-application logging scenarios?
Setup and framework
We conducted the test on a traditional single-node IBM Business Automation Workflow 26.0.0 Process Server environment (@ 4 CPU Cores, 8 GB RAM) with default configuration.
For capturing the logging performance, we used 50 duplicates of a minimal benchmark application that contained a service flow with a single script task that calls four different log methods in a 100-iteration loop, before completing. The execution time of the loop was logged. A multi-threaded test framework would then randomly and continuously invoke the service flows within the 50 applications, simulating 50 concurrent users and incorporating a 20 second think time between each two service flow invocations. This amounted to a total of (net) 1,000 log records written per second.
Performance results
Loop execution time
The loop inside each script task wrote 400 log records of different types and we plotted the loop execution times in the graph below. As can be seen, both application-specific logging scenarios had significantly lower execution times than the baseline scenario. While we see an average of around 35 ms to log 400 statements into SystemOut.log, the application-specific logging scenarios take around 7 ms on average to log the same amount of data. This significant improvement in logging performance led the test service flow to execute faster.
CPU usage comparison
Now, often these types of improvements come with a trade-off in resource usage, whereby we would expect higher CPU usage in this case. While we in fact see an increase in CPU usage for scenario 2 (global log file), the CPU usage for scenario 3 (separate log file per PA) was even slightly lower compared to the baseline scenario.
High-load logging
To further validate our findings, we conducted a high-load test during which we simulated an increased 500 concurrent users for scenario 2. This amounted to around 10,000 records hitting the global log file per second. The results confirmed that the new logging implementation can handle these high loads without performance degradation, as the average time to log 400 records was still at 7ms.
Summary and insights
Overall, our testing revealed some key insights and suggests that enabling the application-specific logging feature can have significant performance benefits in similar workloads.
Improved performance in the tested scenarios compared to default logging
Application-specific logging consistently demonstrated better performance than standard SystemOut.log logging.
Separate log files = best performance
Having a separate log file per Process Application proved to be the most efficient option, with the lowest CPU usage and fastest logging times.
Excellent scalability
No performance degradation was observed when increasing workload from 50 to 500 concurrent users, demonstrating robust scalability of the new feature.
No bottlenecks or contention
The new logging implementation handles concurrent writes efficiently, with no observable bottleneck or contention even under high load.
Potential workflow performance improvement
Since application-specific logging showed up to 5x faster write responses in the test scenarios, using this feature may actually improve overall workflow performance in production environments.
Disclaimer
All performance measurements presented in this blog were obtained in a controlled development lab environment. The tests were conducted on virtual machines running on dedicated hardware to ensure consistency and reliability of results. It is important to note that actual performance in production environments may vary due to differences in workload characteristics, hardware and system configuration.