Forem: Ghofrane WECHCRIA

OrqueIO Benchmarking

Ghofrane WECHCRIA — Fri, 17 Apr 2026 13:44:38 +0000

A deep dive into load testing the open-source Camunda 7 fork with Gatling, Kubernetes, and Prometheus

When your business relies on a BPMN engine to orchestrate critical processes, performance is not just a nice-to-have. It is essential. Every millisecond of latency, every failed request, every resource bottleneck translates directly into business impact.

That is why we put OrqueIO through rigorous performance testing. The results speak for themselves.

What is OrqueIO?

OrqueIO is a production-ready, open-source fork of Camunda 7, the industry-standard BPMN 2.0 workflow engine trusted by enterprises worldwide. It was born from the need for long-term support and continuous improvement without costly migrations. OrqueIO preserves full compatibility with existing Camunda 7 processes while delivering enhanced security, stability, and performance.

For teams facing the end of Camunda 7 support or seeking a vendor-independent BPMN solution, OrqueIO offers a seamless path forward.

What is Gatling?

Before diving into the results, let me explain our testing tool. Gatling is an open-source load testing framework written in Scala. Unlike traditional tools that simulate users with threads (which gets expensive at scale), Gatling uses an asynchronous, non-blocking architecture. This means a single Gatling instance can simulate thousands of concurrent users without breaking a sweat.

Why we chose Gatling:

Code-based simulations: Tests are written in Java, making them version-controllable and easy to integrate into CI/CD pipelines
Realistic load patterns: You can ramp up users gradually, hold steady load, or create complex traffic patterns that mirror real-world usage
Beautiful reports: Gatling generates detailed HTML reports with response time distributions, percentiles, and throughput charts
Low resource footprint: Thanks to its async architecture, you can generate massive load from modest hardware

Our test scenario is straightforward: we repeatedly call the OrqueIO REST API to start new process instances. This is the most common and performance-critical operation in any workflow engine.

POST /engine-rest/process-definition/key/{processKey}/start

Each request creates a new BPMN process instance, persists it to the database, and returns the instance ID. Simple, but it exercises the full stack.

The Testing Setup

We designed our load testing infrastructure to simulate real-world production conditions.

Kubernetes Environment:

Amazon EKS cluster
All components deployed in the same namespace for simplified networking
PostgreSQL database running in EKS for consistent latency

Monitoring Stack:

Prometheus for metrics collection
Grafana Alloy for scraping container metrics
Real-time CPU and memory tracking during test execution

Load Testing Pipeline:

Gatling packaged in a Docker container
Jenkins for orchestration and parameterized test runs
Automatic report upload to S3

The entire setup is automated. We can spin up a test, adjust pod counts, change resource limits, and compare results across configurations with just a few clicks.

The Testing Infrastructure

We built a fully automated testing pipeline that anyone can replicate. Here is how all the pieces fit together:

The Flow:

Trigger: A developer kicks off a Jenkins build, either manually or on a schedule.
Parameters: Jenkins prompts for test configuration. How many pod replicas? What CPU and memory limits? How long should the test run? How many users per second?
Build: Jenkins builds the Gatling Docker image and pushes it to Amazon ECR.
Scale: Before the test starts, Jenkins uses kubectl to scale the OrqueIO deployment to the desired replica count and applies the specified resource limits.
Deploy: Jenkins deploys the Gatling container as a Kubernetes Job in the same namespace as OrqueIO.
Execute: The Gatling pod hammers the OrqueIO REST API with HTTP requests. OrqueIO processes each request and persists data to PostgreSQL.
Monitor: Meanwhile, Grafana Alloy scrapes CPU and memory metrics from all pods and pushes them to Prometheus.
Collect: When the test finishes, the Gatling pod queries Prometheus for resource usage during the test window, bundles everything into a report, and uploads it to S3.

Gatling in Docker: We packaged Gatling in a container along with scripts that automatically query Prometheus during test execution. When a test finishes, we capture not just the Gatling metrics but also the actual CPU and memory consumption of the target pods.

Jenkins Pipeline: Our Jenkins jobs accept parameters for pod count, CPU limits, memory limits, and test duration. This lets us quickly run comparison tests across different configurations without manual intervention.

Prometheus Integration: During each test, we collect container metrics in real time:

CPU usage via container_cpu_usage_seconds_total
Memory usage via container_memory_usage_bytes
Per-pod breakdowns for debugging hotspots

Everything gets uploaded to S3 at the end of each run, so we have a historical record of every test.

Benchmarking:

We ran three tests with different configurations to understand how OrqueIO behaves under various conditions:

Test 1: Single Pod Baseline
Configuration:

1 Pod replica
CPU: 500m request / 2000m limit
Memory: 512Mi request / 1Gi limit
Load: 10 requests per second for 1 minute (600)

Benchmark:
Gatling Report:

Interpretation:

Resource Consumption:

CPU: 0.031 cores average
Memory: 323 MB stable

What this tells us:

The single pod handled all 600 requests with zero failures. The minimum response time of 37ms represents the true baseline , when a request hits the pod with no GC activity. That is impressive for a full BPMN create, database persist, and response cycle.

The interesting story is in the tail latency. Look at the gap between P95 (72ms) and P99 (478ms) : a 6x jump. This is the classic signature of JVM garbage collection. Most requests fly through quickly, but roughly 1 in 100 gets caught waiting for GC.

The resource numbers tell us something important: the pod used only 0.031 cores (6% of requested) and memory sat stable at 323 MB. This pod is not struggling with capacity. It is struggling with GC pauses that happen regardless of load.

Test 2: Horizontal Scaling with 3 Pods

Configuration:

3 Pod replicas
CPU: 500m request / 2000m limit per pod
Memory: 512Mi request / 1Gi limit per pod
Load: 10 requests per second for 1 minute (600)

Benchmark:
Gatling Report:

Interpretation:

Resource Consumption:

CPU: 0.101 cores total (about 0.034 per pod)
Memory: 330 MB per pod

What this tells us:

We tripled the pods but kept the same load. The improvements go far beyond what simple load distribution would explain.

The minimum dropped from 37ms to 34ms : even the best-case benefits from reduced contention. But the real story is tail latency: P99 went from 478ms to just 60ms, an 87% improvement. Maximum response time fell from 758ms to 116ms.

Why? When one pod pauses for GC, the load balancer routes requests to the other two pods. The probability that all three pause simultaneously is tiny.

Most importantly, standard deviation collapsed from 68ms to just 7ms. The system became predictable. Each pod used about 0.034 cores and 330 MB — nearly identical to the single pod test. We did not waste resources. We simply distributed the workload and let each JVM breathe.

Test 3: Sustained Load (2-Hour Endurance Test)

Configuration:

1 Pod replica
CPU: 500m request / 2000m limit per pod
Memory: 512Mi request / 2Gi limit per pod
Load: 10 requests per second for 2 hours

Benchmark:
Gatling Report:

Interpretation:

Response Time Distribution:

Under 800ms: 71,971 requests (99.96%)
800ms to 1200ms: 28 requests (0.04%)
Over 1200ms: 1 request (0.001%)
Failed: 0 requests (0%)

Resource Consumption:

CPU: 0.040 cores per pod average
Memory: 320 MB per pod average, 450 MB per pod peak

What this tells us:

This is the real test. Two hours of sustained load, 72,000 process instances created, and not a single failure. That is production-grade reliability.

The latency profile stayed remarkably consistent with the short test. Minimum response time actually improved to 32ms, and P99 held steady at 65ms. Even after 2 hours, 99.96% of requests completed in under 800ms.

The 1509ms maximum and the 29 requests over 800ms represent rare GC pauses — about 0.04% of traffic. For most applications, this is perfectly acceptable.

Memory tells an interesting story. Each pod averages around 320 MB. Under sustained load, the heap grows as request objects are created, peaking at around 450 MB per pod, then shrinks after garbage collection runs. This sawtooth pattern is exactly how a healthy Java application behaves. No leaks, no OOM kills, no memory pressure. The 2Gi limit gave plenty of headroom for GC to work efficiently.

Key Performance Insights

1. GC Pauses are Solvable Through Architecture

The gap between P95 and P99 in single-pod deployments reveals the cost of garbage collection. But you do not need exotic GC tuning. Running multiple pods lets the load balancer route around pauses naturally.

2. Horizontal Scaling Pays Compound Dividends

Tripling pods gave us more than 3x benefit in tail latency. You get fewer pauses (less load per JVM) AND better handling of remaining pauses (redundancy). These benefits compound.

3. Memory is Stable and Predictable

All tests showed consistent memory usage around 320–330 MB per pod, peaking at 450 MB under load. No memory leaks, no accumulating state. A 512Mi request with 2Gi limit is appropriately sized.

4. CPU is Not the Bottleneck

At 0.03 cores per pod, CPU utilization is negligible. This is typical for IO-bound applications. You can pack OrqueIO pods densely on your nodes.

5. The Database Keeps Up

With response times in the 40–50ms range including database round trips, PostgreSQL has plenty of headroom. Our PostgreSQL pod (500m CPU, 512Mi memory) handled 72,000 inserts over 2 hours without breaking a sweat. The latency spikes come from JVM pauses, not database contention.

Conclusion

OrqueIO proves that open-source BPMN engines can deliver enterprise-grade performance. With sub-50ms median latency, linear scaling characteristics, and predictable resource consumption, it is a compelling choice for organizations seeking a sustainable, high-performance workflow automation platform.

The transition from Camunda 7 to OrqueIO is not just about maintaining compatibility. It is about building on a solid foundation with a clear path forward.

Resources:

OrqueIO Official Website: https://www.orqueio.io
OrqueIO Documentation: https://docs.orqueio.io

Have you tested OrqueIO in your environment? We would love to hear about your experience. Drop a comment below or reach out on GitHub.

Migrate your Drools rules to OrqueIO DMN

Ghofrane WECHCRIA — Thu, 16 Apr 2026 14:32:22 +0000

Introduction

In a business process, decision-making is essential because it defines the logic that guides the execution of activities. Historically, this logic was externalized into rule engines such as Drools, separating decision-making from orchestration. However, in today’s environments where transparency and collaboration are key, this separation reveals its limitations: rules often remain hidden in technical files, difficult to understand and maintain.
To address these challenges, organizations now seek more integrated approaches. This is exactly what OrqueIO DMN offers: a model in which decisions and processes are brought together within the same ecosystem, providing consistency, clarity, and traceability.

1.OrqueIO — The future of open-source orchestration

Before introducing DMN, it’s important to present the execution platform.
OrqueIO is a 100% open-source fork of Camunda, ensuring the long-term future of BPMN automation, maintaining full compatibility with existing workflows while extending and modernizing the engine.

What OrqueIO brings:

100% open-source and fully compatible with your current BPMN/DMN models, connectors, scripts, and APIs
Ongoing maintenance and guaranteed security updates, ensuring long-term reliability and stability
New, practical features for daily use, including improved Cockpit monitoring and native DMN integration
Enhanced performance and engine stability, even under high load
Expert technical support, transparent and reliable — with no vendor lock-in

In summary, OrqueIO enables organizations to preserve their existing investments while adopting a modern, sustainable, and open orchestration platform — an environment where integrated decision logic with DMN naturally thrives.

2. The limitations of Drools

Excessive separation from the BPMN process:
The rules are stored in .drl files, often isolated in a separate project or module, which scatters business logic and makes it difficult to understand the relationship between decisions and the process.

Maintenance complexity:
This separation between the rule engine and the process leads to difficulties in maintaining overall system consistency over time.

Barrier for business teams:
The rules are written in technical languages such as DRL or MVEL, requiring development skills.
Non-technical users cannot read or modify these rules without IT involvement.

Lack of traceability and transparency:
Drools does not natively provide decision traceability (which rules were applied and why).
This makes audits and regulatory compliance much more difficult.

Rigid update cycle:
Any modification to a rule requires a full redeployment of the engine or application module, slowing down update cycles and reducing responsiveness.

Limits in agility and governance:
The Drools model does not encourage collaboration between business and IT teams, nor does it provide clear governance of decision rules integrated into BPMN processes.

3. OrqueIO DMN: a unified, readable, and open-source approach

OrqueIO natively integrates the DMN standard (Decision Model and Notation), enabling the unification of process logic (BPMN) and decision logic within the same platform.
Whereas Drools externalizes rules into a separate rule engine, OrqueIO provides an integrated, visual, and transparent approach within a recognized open-source automation ecosystem.

Clear and accessible rule representation
In OrqueIO, decisions are modeled as DMN decision tables.
Each row represents a rule, and each column represents a condition or an output.
This visual format is understandable to both business users and developers, replacing the DRL or MVEL source code used in Drools.
Business analysts can define, adjust, and validate decision logic without heavy reliance on technical teams.

Native BPMN ↔ DMN Integration
In OrqueIO, a Business Rule Task can directly invoke a DMN decision table from within the same project.
No external connectors, no complex integration: the process and the decision belong to the same executable model.
This results in a decision logic that is coherent, centralized, and fully traceable across the entire workflow.

Built-in traceability and audit
Every decision execution is automatically logged.
Teams can easily review:

which rules were evaluated,
the input values,
and the resulting outputs.

This greatly simplifies audits, gap analysis, regulatory compliance, and continuous improvement.

A complete and consistent ecosystem
OrqueIO provides a unified environment combining:

BPMN for process orchestration,
DMN for decision logic,
Cockpit for monitoring and analysis.

Everything is centralized, extensible, interoperable, and designed to enhance collaboration between business teams and IT.

4. Why migrate to OrqueIO DMN?

The transition from Drools is not just a tool replacement —
it is the adoption of a more agile, readable, and collaborative decision model.

Centralization of decisions and processes
Decisions are no longer isolated in a separate technical module.
They coexist with business processes within the same execution environment, ensuring a unified and coherent view of the system’s behavior.

Simplified maintenance
Modifying a rule no longer requires redeploying the application.
A simple update to the DMN decision table is enough to adjust the business logic, reducing delivery cycles and improving operational responsiveness.

Enhanced collaboration
Business teams design and adjust rules, while developers focus on integration and robustness.
The result: fewer misunderstandings, fewer back-and-forth steps, and greater overall efficiency.

Monitoring and transparency
With the Cockpit interface, every executed decision is observable, explainable, and interpretable.
This transparency simplifies optimization, control, and regulatory compliance.

Below is a comparison table summarizing the main differences between Drools and OrqueIO:

5.Concrete example of the transition: from Drools to OrqueIO DMN

We want to apply discounts based on:

the customer type (Standard, Premium, VIP)
the order amount (orderAmount)

Drools version (Before)
This .drl file contains the rules, written in Drools syntax

import io.orqueio.bpm.exemple.dmn.model.Order;

rule "Standard < 100"
    when $o : Order(clientType == "Standard", orderAmount < 100)
    then $o.setDiscount(0);
end

rule "Standard 100..500"
    when $o : Order(clientType == "Standard", orderAmount >= 100 && orderAmount <= 500)
    then $o.setDiscount(5);
end

rule "Standard >= 500"
    when $o : Order(clientType == "Standard", orderAmount > 500)
    then $o.setDiscount(8);
end

rule "Premium < 100"
    when $o : Order(clientType == "Premium", orderAmount < 100)
    then $o.setDiscount(10);
end

rule "Premium 100..500"
    when $o : Order(clientType == "Premium", orderAmount >= 100 && orderAmount <= 500)
    then $o.setDiscount(15);
end

rule "Premium >= 500"
    when $o : Order(clientType == "Premium", orderAmount > 500)
    then $o.setDiscount(20);
end

rule "VIP < 500"
    when $o : Order(clientType == "VIP", orderAmount < 500)
    then $o.setDiscount(20);
end

rule "VIP 500..1000"
    when $o : Order(clientType == "VIP", orderAmount >= 500 && orderAmount < 1000)
    then $o.setDiscount(25);
end

rule "VIP >= 1000"
    when $o : Order(clientType == "VIP", orderAmount >= 1000)
    then $o.setDiscount(30);
end

Implementation with DMN in OrqueIO

With DMN, the decision logic is defined in the form of a decision model, in which we explicitly describe:

which data serves as inputs to the decision,
which conditions are applied,
and which result must be produced.

This model can be edited visually, either as a table or as a diagram, which allows business teams to understand and adjust the logic more easily.

At the same time, that same logic is stored in a standard DMN XML file, which is used by the engine for execution.
The graphical view and the XML view are simply two representations of the same model, always kept in sync.

In the BPMN diagram, you simply add a Business Rule Task:

Calling a decision does not require any complex configuration.
In the BPMN diagram, a simple Business Rule Task is enough.
You only need to specify the decision reference (the ID defined in the DMN model), and the engine takes care of the evaluation.No additional technical configuration is required.
The decision is executed automatically when the BPMN flow reaches the decision task.

Conclusion

Migrating from Drools to OrqueIO DMN is more than a modernization effort — it is a strategic shift toward transparency, agility, and collaboration. By bringing decision logic closer to BPMN processes, organizations eliminate silos, simplify maintenance, and empower business teams to directly contribute to the evolution of rules. The result is a unified, traceable, and adaptable system where decisions are easier to understand, update, and audit.

With OrqueIO DMN, your business logic becomes clearer, your delivery cycles faster, and your governance stronger. This transition enables organizations to move from rigid rule engines to an integrated decision model that supports continuous improvement and operational efficiency.

🌐 Learn more about OrqueIO
📂 Explore the example Order Process from the OrqueIO webinar

Camunda 7 End of Life: Why More Teams Are Choosing OrqueIO as Their Migration Alternative

Ghofrane WECHCRIA — Thu, 16 Apr 2026 13:48:23 +0000

With Camunda 7 Community Edition now officially reaching end of life, many organizations are asking the same question:

What comes next for our workflow orchestration platform?

For teams heavily invested in BPMN automation and process orchestration, the obvious path may seem to be migrating to Camunda 8.
But in reality, many companies quickly discover that moving to Camunda 8 is far from a simple upgrade.

It often requires:

Major process refactoring
New infrastructure and architecture changes
Reworking integrations and deployment pipelines
Significant investment in time, budget, and training

For organizations running large-scale orchestration environments, this can represent a major technical and business challenge.

That’s exactly why we built OrqueIO.

OrqueIO: A Modern Open-Source Alternative to Camunda 7

OrqueIO is a modern, long-term supported fork of Camunda 7, designed for organizations that want to preserve their existing workflow architecture without going through a painful migration.

Instead of rebuilding everything from scratch, OrqueIO allows teams to continue running their BPMN processes and applications on a modernized, future-proof foundation.

With OrqueIO, you get:

Full compatibility with existing Camunda 7 BPMN/DMN models and APIs
Java 25, Spring Boot 4 and Angular modern stack
Continuous security updates and platform improvements
Free and open-source licensing
Optional enterprise support for production environments

In short:

OrqueIO enables you to keep your Camunda 7 investment while moving forward with a modern platform.

Built for Enterprises That Need Stability and Continuity

OrqueIO was not created as an experimental fork.

It was designed by engineers with real-world enterprise experience operating Camunda-based systems in large production environments.

Our goal was simple:

Preserve compatibility. Remove technical debt. Modernize the platform.

This means organizations can benefit from:

smoother upgrades,
lower migration risk,
reduced maintenance overhead,
and long-term platform sustainability.

More Than a Fork: A Platform Evolving Beyond Camunda 7

While compatibility remains at the core of OrqueIO, our ambition goes further.

Our roadmap includes a growing set of enterprise-ready capabilities to make orchestration smarter, simpler, and more secure:

Single Sign-On (SSO) and centralized identity management
Enhanced observability and analytics dashboards
Built-in documentation and model insights directly in the UI
Continuous UI/UX modernization across all modules

Our philosophy remains unchanged:

Keep compatibility. Add value. Evolve continuously.

The Future of Camunda 7 Doesn't Have to End Here

Camunda 7 may have reached end of life, but that does not mean organizations need to abandon their architecture or rebuild everything.

For teams looking for a Camunda 7 alternative, Camunda 7 fork, or open-source workflow engine compatible with existing BPMN applications, OrqueIO provides a pragmatic path forward.

If your company wants to modernize without rewriting years of orchestration logic, OrqueIO may be exactly what you’re looking for.

Learn more about OrqueIO: https://www.orqueio.io

Camunda 7 EOL — What Comes Next?

Ghofrane WECHCRIA — Thu, 16 Apr 2026 10:39:30 +0000

Introduction

Camunda 7 Community Edition, one of the most widely used BPMN workflow engines, reached its end of life in October 2025. For many enterprises, this marks a critical turning point: running business-critical workflows on an unsupported platform can create security risks, operational challenges, and technical debt.

As organizations look for ways to maintain continuity and stability, it's essential to explore alternatives that preserve existing processes without major disruptions. OrqueIO, the most modern fork of Camunda 7, offers a practical solution for teams that want to keep the trusted architecture of Camunda 7 while gaining long-term support, security, and flexibility.

End of Life of Camunda 7 Community

In October 2025, Camunda 7 Community Edition reached its official end of life, with the final release (v7.24) published on October 14, 2025. Since then, Camunda 7 CE no longer receives updates, security patches, or official support.

Any production environment running Camunda 7 CE after that date faced increased security risks and potential operational issues. For enterprises relying on Camunda 7 to manage critical workflows, this resulted in higher maintenance costs, accumulated technical debt, and reduced system stability. Without vendor support, addressing bugs or vulnerabilities became more difficult, making business continuity a real challenge.

The Risks of Staying on Camunda 7 CE

Continuing to run Camunda 7 Community Edition after its end of life comes with several risks for enterprises:

Technical debt: Outdated workflows and custom extensions may become harder to maintain.
Security vulnerabilities: Without updates or patches, systems are more exposed to attacks.
Maintenance challenges: Troubleshooting and fixing issues without official support can slow down operations.
Impact on critical processes: Business-critical workflows may experience downtime or instability, affecting overall productivity and reliability.

Choosing the right path now can prevent disruptions and ensure that workflows continue running smoothly.

Migration to Camunda 8: A Complex Journey

Moving from Camunda 7 CE to Camunda 8 involves a complex process. Enterprises should be aware of the challenges involved:

Workflow adjustments: Existing BPMN models can often be migrated, but some elements, attributes, and extensions from Camunda 7 may need modification to run on Camunda 8.
New architecture: Camunda 8 uses a cloud-native, event-driven platform that differs significantly from Camunda 7.
Team adaptation: Developers and operators need to become familiar with Camunda 8's APIs, operational patterns, and new workflow tools.
High migration cost: Moving to Camunda 8 requires significant time, resources, and financial investment, especially for organizations with complex workflows.

While Camunda 8 introduces modern features, the migration effort can be significant, especially for organizations with complex or mission-critical workflows.

OrqueIO: A Camunda 7 Alternative

OrqueIO is the most modern fork of Camunda 7, designed to provide enterprises with a seamless path beyond Camunda 7 CE without disruptions or rewrites. It allows teams to maintain their existing BPMN workflows, APIs, and extensions while benefiting from a modern, continuously evolving platform.

Key benefits of OrqueIO:

Operational continuity: High availability and business continuity with zero code rewriting, keeping your BPMN workflows fully stable and running smoothly.
Innovation and modern architecture: A continuously evolving platform, adding new features, optimizations, and enhancements to stay modern and reliable.
Optimization: Simplified design and performance-focused execution, ensuring efficient and reliable processes.
Security: Native security features to protect workflows, data, and integrations.
Documentation: Clear, practical, and usable technical documentation for developers and operators.
Enterprise support: Dedicated support with SLA and guaranteed response times.

OrqueIO ensures continuity, stability, and scalability, giving enterprises confidence as they evolve their workflow automation.

Conclusion

Camunda 7 Community Edition reached its end of life in October 2025, leaving enterprises running critical workflows in need of a reliable path forward. Continuing on an unsupported platform exposed businesses to security risks, technical debt, and operational challenges.

OrqueIO provides a practical, future-proof alternative. With full compatibility for existing workflows, APIs, and extensions, enterprises can maintain business continuity with zero code rewriting and without major infrastructure changes. Combined with dedicated support, continuous updates, and flexible deployment options, OrqueIO enables organizations to evolve their workflow automation securely and confidently.

Want to see OrqueIO in action?

📩 Contact us at contact@orqueio.io to schedule a personalized demo
or visit our official website: www.orqueio.io/contact

📚 Resources :

Documentation: https://docs.orqueio.io/
GitHub: https://github.com/OrqueIO