{"id":342746,"date":"2022-10-05T14:16:00","date_gmt":"2022-10-05T12:16:00","guid":{"rendered":"https:\/\/www.optimal-systems.de\/?p=342746"},"modified":"2024-05-17T16:22:58","modified_gmt":"2024-05-17T14:22:58","slug":"yuuvis-rad-7-major-improvements-in-workflow-performance","status":"publish","type":"post","link":"https:\/\/www.optimal-systems.de\/en\/digitalization\/blog\/yuuvis-rad-7-major-improvements-in-workflow-performance","title":{"rendered":"yuuvis\u00ae RAD 7: Major Improvements in Workflow Performance"},"content":{"rendered":"\n
<\/span>\"Eine\"A
\n
\n
\n

Date<\/span><\/p>\n\n\n\n

yuuvis\u00ae RAD 7: Major Improvements in Workflow Performance<\/h1>\n\n\n\n

by Michael Gronau, Lars Nock, Bratislav Mili\u0107<\/p>\n<\/div>\n<\/div>\n<\/div><\/div><\/div>\n\n\n

\n
\n
\n

When launching a new major version of a product, it is common practice to prepare a set of new features. They are easy to present and provide something tangible to users and system administrators. While as important as new features, technical improvements such as code refactoring and architecture enhancements usually remain hidden or are at best seen as a sidenote in release notes.<\/p>\n\n\n\n

In yuuvis\u00ae RAD version 7, however, we decided to focus on technical improvements that optimize parts of the server code and enhance the overall system architecture, making version 7 up to 5.8 times faster in certain metrics than version 6.16 LTS. This article quantifies the major refactoring that we performed on the workflow functionality in yuuvis\u00ae RAD and compares the two successive versions of our product to demonstrate the benefits of the new architecture.<\/p>\n\n\n\n

Workflow in yuuvis\u00ae RAD 6<\/h2>\n\n\n\n

In version 6 of yuuvis\u00ae RAD, the workflow logic was shared between two services: the core service was doing most of the work, implementing the logic of each step in the process execution (such as writing the history, handling the substitution rules, executing scripts, etc.). The bpm service controlled the activity processing within a process (moving a process from one state to another) and provided a REST interface for clients to list processes, see and manipulate their files, or to get the process history.<\/p>\n\n\n\n

In our performance analysis of yuuvis\u00ae RAD 6, we observed that this setup was limiting to the level of asynchronicity that we were aiming for. Since the bpm service contained the logic that triggers the progress of a process to the next state, it had to make a blocking REST call that will just execute this transition in the core service. Since the REST call blocked the thread until it finishes (it was necessary to guarantee the correct ordering of execution of workflow steps), the bpm service was unable to fully utilize its threads and the overall workflow throughput was throttled down.<\/p>\n\n\n\n

yuuvis\u00ae RAD 7: Redesigning the Services and other Technical Improvements<\/h2>\n\n\n\n

Starting with version 7, we decided to follow stricter rules of separation with regard to service responsibilities. The focus of the bpm service is now to provide clients with REST APIs to query processes, whereas the logic that controls the complete execution of processes is centralized in the core service. In consequence, inter-service communication, which occurred in yuuvis\u00ae RAD 6, can be completely avoided.<\/p>\n\n\n\n

The main benefit of the new architectural solution brought by yuuvis\u00ae RAD 7 is that the delays introduced by the service-to-service communication over REST no longer exist. The state of a process is progressed with a simple call within the core service, and the threads are no longer blocked for longer time periods.<\/p>\n\n\n\n

In addition to optimizations in architecture and code, the Java version in the yuuvis\u00ae RAD core service was updated from Java 8 in version 6 to Java 11 in version 7. Java 11 brings various new features, but for the purpose of this article the most important one is the improved garbage collector, which further increases the performance of the core service by several percent.<\/p>\n\n\n\n

Putting the Improvements to the Test: Setup and Hardware<\/h2>\n\n\n\n

For benchmark execution, we used a workstation with an Intel Core i7-6700 CPU, 32 GB of RAM, and a Samsung PM871a 512 GB SSD. The core service executing the workflow functionality was limited through its configuration to only 2 GB of RAM. The database used by yuuvis\u00ae RAD for storage was MS SQL Server 2014 and was run on the same workstation.<\/p>\n\n\n\n

Benchmark Methodology<\/h2>\n\n\n\n

For each of the tested scenarios, we start a batch of 1,000 processes and measure:<\/p>\n\n\n\n