Place in first available node with sufficient resources
0
Active Functions: 0
Active Nodes: 0
Queued Requests: 0
Cold Start Executing Available
API Gateway
Incoming Request
Request Dispatcher
Queue empty
Dispatch Request
Compute Nodes will appear here...
Cold Start Times
Routing Strategy Battleground
Compare two routing strategies side-by-side with the same simulation settings.
0
Strategy A: Warm Priority | First Fit
Funcs: 0
Nodes: 0
Queue: 0
Gateway A
Dispatcher A
Queue empty
Nodes will appear...
Strategy B: Round Robin | Best Fit
Funcs: 0
Nodes: 0
Queue: 0
Gateway B
Dispatcher B
Queue empty
Nodes will appear...
Battleground Session Performance Comparison:
Average Latency Over Time:
Resource Utilization Metrics:
Active Functions Over Time:
Infrastructure Growth (Nodes) Over Time:
Cost Analysis (Execution Time × Memory):
Placement Algorithm Analysis
Current Placement Algorithm:
First FitPlace in first available node with sufficient resources
Placement Algorithm Performance Comparison:
Function Distribution Across Nodes:
Placement Performance Over Time:
Placement Algorithm Testing Guide:
1
Select Algorithm
Choose a placement algorithm from the dropdown in the Visualizer Controls panel
2
Send Requests
Send multiple requests to generate placement data and see how functions are distributed
3
Analyze Results
View performance metrics and distribution charts to understand algorithm behavior
4
Compare Algorithms
Switch algorithms and compare performance using the Battleground for side-by-side analysis
Select Request Routing Logic
Warm Priority Routing Details:
Priority to Warm Functions: Incoming requests are first directed to any currently warm (green) function instance that has available concurrency slots. This minimizes latency by utilizing existing resources.
Queueing: If no warm functions are immediately available, requests are added to a FIFO (First-In, First-Out) queue. This provides a buffer for traffic spikes and prevents request loss.
Scale-Out Trigger:If the queue is not empty and all existing functions are either busy or cold-starting, the system attempts to spin up a new function instance (and potentially a new compute node if needed, based on Max Nodes limit). This ensures capacity keeps up with demand.
Queue Draining: As functions complete tasks or new functions become warm after a cold start, they immediately pull requests from the front of the queue, ensuring rapid processing of backlog.
Round Robin Logic Details:
Sequential Distribution: Requests are distributed in a simple, sequential manner to all available (warm and not at max concurrency) function instances.
Fair Distribution: This method aims to achieve a relatively even distribution of load across all available functions, as it cycles through them one by one.
Simple to Implement: It's a straightforward strategy that doesn't require complex load metrics.
Limitations: It doesn't account for individual function load or performance variations, which might lead to an imbalance if functions have different processing speeds or existing workloads.
Least Connections Logic Details:
Dynamic Load Balancing: Requests are routed to the available function instance that currently has the fewest active (busy) requests.
Optimal Resource Utilization: This method is generally more effective than Round Robin at distributing load evenly in scenarios where functions might have varying processing times or where new functions are spinning up.
Reduced Latency: By sending requests to the least busy function, it aims to minimize waiting times and overall request latency.
Requires State Tracking: This logic requires the dispatcher to keep track of the current number of active requests for each function instance to make an informed routing decision.
Requests Performance in Current Session:
Simulation Results Graph (Cumulative):
Resource Utilization & Queue Metrics Over Time:
Download Simulation Data:
Note: This data is temporary and will be lost if you refresh the page or close your browser tab.
Function Instance Provisioning and Binding
Current Simulation Logic:
Function Type Selection: When a new function instance needs to be provisioned (due to scaling out), it will be of the Default Function Type currently selected in the Visualiser tab's control panel. Each function type has its own defined CPU and Memory consumption.
Finding an Existing Node: The system first attempts to find an existing Compute Node that can host the new function. A node is considered suitable if:
It has not yet reached its Max Functions per Node limit.
It has sufficient available CPU (Node Max CPU - current CPU usage) to meet the Function CPU Consumption of the selected function type.
It has sufficient available Memory (Node Max Memory - current Memory usage) to meet the Function Memory Consumption of the selected function type.
New Node Provisioning: If no existing Compute Node can accommodate the new function (either due to hitting Max Functions per Node or lacking sufficient CPU/Memory resources for the selected function type), the system attempts to provision a new Compute Node. This only happens if the Max Compute Nodes limit has not been reached.
A new node is only provisioned if its default Node Resource Capacity (CPU and Memory) is sufficient to host at least one function instance of the selected function type.
Resource Allocation: When a function instance is placed on a node (new or existing), its configured CPU and Memory consumption are immediately reserved and deducted from that node's available resources.
Resource Deallocation (Scale-Down): When a function instance scales down due to inactivity, its consumed CPU and Memory resources are released back to its hosting Compute Node, increasing the node's available capacity. Similarly, when a node itself scales down, all its resources are considered released from the system.
Future Enhancements / Different Strategies:
Resource Optimization: Implement more intelligent placement strategies (e.g., bin packing, least utilized node) to optimize resource utilization (CPU, memory) across nodes.
Fault Domain Awareness: Distribute functions across different physical hardware or availability zones to improve resilience.
Cost Optimization: Introduce logic to prefer placing functions on nodes with lower operational costs or to consolidate workloads to reduce the number of active nodes.
Affinity/Anti-affinity: Allow configuration to group related functions on the same node (affinity) or keep unrelated functions separate (anti-affinity) for performance or isolation.
Container Orchestration Integration: Simulate how a full-fledged container orchestrator (like Kubernetes) would handle pod scheduling and placement for serverless functions, including advanced concepts like node taints/tolerations or resource quotas.
About Serverless Visualiser
Core Functionality:
Simulate serverless function scaling based on incoming requests.
Visualize cold starts and their impact on latency.
Implement a request queue to handle bursts of traffic.
Dynamically add/remove compute nodes and function instances.
Configurable Parameters:
Max concurrent requests per function.
Max number of compute nodes.
Cold start delay duration.
Inactivity timeout for scaling down.
Min/Max request execution time.
Adjustable auto-request rate.
User Interface:
Clear and intuitive representation of serverless architecture components (API Gateway, Dispatcher, Compute Nodes, Functions).
Visual indication of function states (cold starting, busy, available).
Real-time metrics for active functions, nodes, and queued requests.
Smooth visual flow transitions for requests.
Responsive design for various screen sizes.
Modular UI with a collapsible control panel.
Multi-page/tabbed interface for separate sections (e.g., Visualiser, About, Routing Logic, Binding Logic).