Throttling

Description

The throttling function is a powerful and versatile feature available since Orchestra 4.15. It is used to limit the number of allowed requests or concurrent processes, regardless of the source of the trigger. The primary objective is to enhance the resilience, robustness, and performance of your system by restricting the number of requests processed in parallel. This feature allows for the application of throttling rules at different levels, including individual input channels, scenarios, or the entire system instance. Notifications can also be triggered when any defined rule is activated.

Functionalities

• Request Throttling:
  The throttling function enables the limitation of requests per time unit to utilize your application's resources efficiently and prevent overloads.

• Process Throttling:
  Define the maximum number of processes allowed to run simultaneously, regardless of their triggering mechanism. This control helps maintain system resources and ensures stability.

• Flexible Configuration:
  Throttling rules can be configured based on the specific requirements of your solution. You can define specific time intervals, triggers, or conditions.

• Control Options:
  This feature provides the flexibility to apply throttling rules at varying levels, including the ability to set individual rules for input channels, scenarios, or the entire system instance.

• Notification Function:
  Real-time notifications are triggered when a throttling rule is violated, promptly informing administrators and responsible parties of rule violations for quick action.

Use Cases

• Time-Consuming Processes:
  Ensure that only one instance of a long-running, timer-based process is started, even if the timing interval is longer than the execution time of the process. Example: Timer-based synchronization of master data between an ERP system and a database.

• Bulk Data from External Source:
  Limit the number of external events (e.g., files, messages from a queue) that can be executed simultaneously. Example: Process only 10 files in parallel instead of processing all files in a directory at once.

• API Gateway:
  Restrict a client to a predetermined number of requests within a specified time interval (e.g., 5 requests per minute). Example: Prevent denial of service attacks by limiting HTTP requests from external clients.

• Orchestra Cell System:
  Accept cell signals only if Orchestra can process the received signal quickly enough. Otherwise, do not accept signals. Example: Prevent Orchestra in cell mode from being overwhelmed with signals from an external cell, especially in the event of a network failure.

• Limit CPU Utilization:
  Restrict the execution of processes if CPU utilization surpasses specific thresholds. Example: To manage the load on the Orchestra server during time-consuming operations, impose limits to prevent system performance degradation.

Benefits

• Improved System Stability and Performance:
  The throttling feature ensures that only a predefined number of processes can be executed concurrently, enhancing performance and reducing resource occupation by queuing processes.

• Protection Against DDoS Attacks:
  Throttling mitigates DDoS attacks by limiting the number of requests per second, thereby improving system security.

• Efficient Resource Utilization:
  By preventing the overuse of resources, throttling ensures that existing resources are used effectively.

• Rapid Response to Outages and Security Threats:
  Notifications are generated when throttling limits are exceeded, enabling administrators to respond promptly to resource outages or security threats.

Summary

A set of throttling rules exists that defines the conditions under which the state of Orchestra is considered valid. Various Orchestra components (process models, scenarios, remote API, cell communications, or global) can be constrained by applying these rules. If the state experiences overflow, incoming requests will be rejected. The method of rejecting external events depends on the underlying protocol. In web-based communication, the sender receives an error code and a retry-later header indicating the retry time for a rejected request. In polling channels, regular polling operations are suspended until resource availability is restored.

• The tab "Throttling Assignment" is detailed in the section "Throttling Assignment".
• The tab "Throttling Rules" is discussed in the section "Throttling Rules".
• The tab "Notification Settings" is covered in the section "Notification Settings".

note

To view Assignments and Rules in the Monitor, users must have the role "Throttling.View". To create or modify these, users must have the role "Throttling.Modify".