Metrics Quick Reference

This page provides a comprehensive quick reference for all metrics used in NetFUNNEL's real-time monitoring and statistics, organized by traffic control flow stages. Use this to quickly understand what each metric means and where it fits in the overall traffic control process.

Traffic Control Flow Overview

The following diagram shows the complete traffic control flow and where each metric is measured:

Metrics by Traffic Flow Stage

Stage 1: Request Arrival

Metric	Real-time Monitoring	Statistics	Unit
Entry Requests	Default: Entry Requests Classic: Entry	Inflow	TPS
All Requests	(not shown)	All Requests	TPS

Entry Requests:

• Definition: Average number of initial entry requests per second, measured as requests per second (TPS) within a specific time window
• Simple explanation: This shows how many users on average attempt to access your service for the first time each second
• What it tells you: Helps you estimate the raw traffic volume that would have hit your service without NetFUNNEL, providing insight into the pure demand before traffic control is applied
• Interpretation: A high value indicates many users are attempting to access your service simultaneously. This metric represents the demand side of traffic - how many people want to use your service. Each request represents a new user attempting to enter a service that has a waiting room applied
• Key Insights: This is the raw demand entering your system. Higher values mean more concurrent access attempts. Some of these requests may bypass the waiting room if they're below the Limited Inflow threshold, while others will move to the waiting room when Limited Inflow is exceeded

All Requests:

⚠️ Important: There are two different "All Requests" metrics with different scopes:

1. Project/Segment Level All Requests:

   • Definition: Average TPS of all traffic control API calls made by NetFUNNEL agents. This includes: Initial Entry Request, Re-entry Request, Alive Notice Request, and Complete Request
   • Simple explanation: This shows the total traffic control communication volume between your application and NetFUNNEL servers
   • What it tells you: Helps you understand the overall traffic control communication load and capacity planning for traffic control operations

2. NetFUNNEL Server Level All Requests:

   • Definition: Average TPS of ALL types of API requests to the NetFUNNEL server, including traffic control requests, data query requests, administrative API requests, and all other API calls
   • Simple explanation: This shows the total number of requests that the NetFUNNEL server processes each second across all operations
   • What it tells you: Enables server engineers to gauge the total system load from a server infrastructure perspective, helping you understand the complete workload including all API calls and traffic control operations at the NetFUNNEL server level

Key Points:

• Real-time: Shows current demand - how many users are attempting to enter right now
• Statistics: Shows historical average of initial entry requests

Stage 2: Capacity Decision

Metric	Real-time Monitoring	Statistics	Unit
Limited Inflow	Limited Inflow	Limited Inflow	-
Active Users	Default: Current number of users Classic: Current number of users	Users	pax
Active User Rate	Default: Current usage rate Classic: Current usage rate	(not shown)	%

Limited Inflow:

• Definition: The configured limit value that restricts the number of concurrent active users for the service, displayed as a snapshot at the time of measurement
• Simple explanation: This is the maximum number of users allowed to use the service simultaneously at any given time, like setting a maximum occupancy limit
• What it tells you: Provides context for interpreting other metrics by showing the capacity limit in effect when those metrics were recorded, enabling you to make informed capacity adjustment decisions

Active Users:

• Definition: The number of users actively using the service between service entry and service exit, displayed as a snapshot value at the time of measurement
• Simple explanation: This shows how many users are currently inside the service using it at the moment of measurement
• What it tells you: Enables you to assess current capacity utilization by comparing active users against the Limited Inflow limit, helping you determine if capacity adjustments are needed
• Calculation: +1 when a request receives PASS and enters the service, -1 when a request exits the service (explicit key return)
• Critical Relationship: This value is directly related to Limited Inflow. NetFUNNEL's core principle is to keep Active Users below Limited Inflow. When Active Users approach Limited Inflow, NetFUNNEL stops issuing PASS responses and instead sends WAIT responses, directing requests to the waiting room

Active User Rate:

• Definition: The percentage of Limited Inflow currently being used, calculated as (Active Users / Limited Inflow × 100) at the time of measurement
• Simple explanation: This shows what percentage of the maximum allowed capacity is currently occupied by active users
• What it tells you: Helps you evaluate capacity utilization efficiency, where a high rate indicates full utilization and a low rate suggests available capacity for additional users
• Interpretation: 100% means capacity is fully utilized, ~80% means capacity is likely at or near 100% (due to monitoring resolution limitations), 50% means approximately half of capacity is available, <50% means significant capacity available
• Monitoring Resolution Consideration: NetFUNNEL servers process a very large number of requests in real-time at high speed. The monitoring system's resolution may not be able to keep up with this rapid processing. Therefore, when you see an Active User Rate around 80%, you should interpret it as the system likely operating at or near 100% capacity, not as having 20% remaining headroom

Monitoring Resolution Limits

Due to NetFUNNEL's high-speed request processing, the monitoring resolution may not capture every rapid state change. An Active User Rate of 80% should be treated as effectively 100% capacity utilization. Plan capacity adjustments accordingly.

Key Points:

• NetFUNNEL compares Active Users to Limited Inflow to decide PASS or WAIT
• If Active Users < Limited Inflow → PASS (direct entry)
• If Active Users ≥ Limited Inflow → WAIT (go to waiting room)

Stage 3: Waiting Room

Metric	Real-time Monitoring	Statistics	Unit
Queue Size	Default: Queue Classic: Queue	Queue	pax
Wait Time	Default: Wait Time Classic: Wait Times	Wait Time	sec
Waiting Status	Default: Waiting Status Classic: Waiting Status	(not shown)	—
Expected Dropouts	Default: Expected Dropouts Classic: Expected Dropouts	(not shown)	pax

Queue Size:

• Definition: The average number of users waiting in the waiting room, calculated within a specific time window
• Simple explanation: This shows the average number of users who were waiting in the queue during the measurement period
• What it tells you: Helps you monitor demand pressure on the system by tracking how many users are waiting to enter, enabling you to assess whether capacity adjustments are needed to reduce wait times
• Interpretation: This is the current queue size, not a historical average. A high value doesn't necessarily mean there's a problem - consider it alongside wait times. The queue grows when Entry Requests exceed the available capacity (Limited Inflow minus Current Users)
• Relationship with Other Metrics: Queue size is influenced by Entry Request Speed (demand) and limited by Limited Inflow (capacity). Queue size should be evaluated together with Waiting Time for a complete picture
• Note on Expected Dropouts: Queue Size includes users who have closed their browser or lost connection (Expected Dropouts). The actual number of actively waiting users is approximately (Queue Size - Expected Dropouts). Consider Expected Dropouts when interpreting queue size for capacity planning decisions

Interpreting Queue Size

A high queue size alone doesn't indicate a problem. Consider it alongside Waiting Time. If the queue is large but wait times are short, users aren't waiting long. If both are high, you may need to increase capacity.

Wait Time:

• Definition: The average waiting time experienced by all users waiting in the waiting room, calculated within a specific time window
• Simple explanation: This shows the average number of seconds that users waited before entering the service during the measurement period
• What it tells you: Enables you to evaluate user experience by assessing whether wait times are acceptable, helping you identify when Limited Inflow may be set too low relative to demand
• Interpretation: This metric represents user experience quality - how long users must wait. Should be evaluated together with Queue Size for complete context. Lower values generally indicate better user experience
• Operational Considerations: NetFUNNEL doesn't directly monitor your server's internal state (CPU, memory, I/O load). Instead, it uses indirect indicators. If you observe high queue size AND high wait time, but your server resources are actually underutilized, this suggests your Limited Inflow may be set too low. You have capacity to accept more traffic, but the "gate" is opened too narrowly. Consider increasing Limited Inflow by 10-20%

Queue Size vs Wait Time

Always consider Queue Size and Wait Time together:

• Large queue + short wait time = Many users, but quick processing
• Large queue + long wait time = Limited Inflow may be set too low (capacity issue likely)
• Small queue + long wait time = Limited Inflow is likely set too conservatively low (very likely)

Waiting Status:

• Definition: A visual indicator that categorizes wait time into three status levels (Fast/Medium/Slow) based on predefined average wait time thresholds
• Simple explanation: This divides wait time into three categories: Fast (원활), Medium (대기), and Slow (지연), providing a quick status overview
• What it tells you: Provides immediate visual insight into waiting conditions without requiring interpretation of specific time values, enabling quick assessment of system performance

Expected Dropouts:

• Definition: The number of users who entered the waiting room but then closed their browser or lost connection, displayed as a snapshot value at the time of measurement
• Simple explanation: This shows how many users are counted in the queue but are not actually waiting because they closed their browser or lost connection
• What it tells you: Helps you understand the difference between the reported queue size and the actual number of users actively waiting, enabling more accurate capacity planning and queue management decisions

Stage 4: Service Entry

Metric	Real-time Monitoring	Statistics	Unit
Inflow	Default: Inflow Classic: Inflow	(not shown)	TPS

Inflow:

• Definition: Average number of users entering the service per second, calculated as requests per second (TPS) within a specific time window
• Simple explanation: This shows how many users actually enter the service each second, including both direct entries and entries after waiting
• What it tells you: Enables you to measure NetFUNNEL's effectiveness by comparing actual service entry rate (Inflow) against initial demand (Entry Requests), helping you understand how much traffic reduction has been achieved
• Key Differences: Entry Requests represents all attempts to enter (before NetFUNNEL processing), while Inflow represents only requests that receive PASS and enter the service (after NetFUNNEL processing)
• Sources of Inflow: Inflow includes requests that enter through two paths: 1) Direct entry - initial requests that immediately receive PASS (when below capacity), 2) Re-entry - requests from the waiting room that receive PASS after waiting
• Why This Metric Matters: Shows the actual load your service is receiving. Demonstrates the effectiveness of NetFUNNEL's traffic control. For example, if you previously received 100 RPS, and after applying NetFUNNEL it's 20 RPS, your service load has actually been reduced to 1/5

Key Points:

• Real-time Inflow: Requests that received PASS and entered service (includes direct entry + re-entry from waiting room)
• Statistics: In Statistics view, "Inflow" refers to initial entry requests (Stage 1: Request Arrival), not service entry rate. For detailed explanation, see Statistics Metrics

Stage 5: Service Usage

Metric	Real-time Monitoring	Statistics	Unit
Process Time	Default: Process Time Classic: (not displayed)	Processing Time	sec

Process Time:

• Definition: The average time duration from service entry to service exit, calculated from data collected within a specific time window
• Simple explanation: This shows the average length of time that users remain actively using the service, from when they enter until they exit
• What it tells you: Serves as an indirect indicator of server load and performance, helping you determine whether Limited Inflow adjustments are needed based on whether process times are increasing or decreasing
• Interpretation by Integration Type: The exact meaning depends on where you apply NetFUNNEL:
  • Code-based Integration Example: Entry is user clicks login button (triggers nfStart()), Exit is login completes and main page loads (triggers nfStop()), Process Time is time to perform login logic and load main page
  • URL-Triggered Integration Example: Entry is user accesses event page URL (enters waiting room, then receives PASS), Exit is event page fully loads, Process Time is time to load and render the event page
  • Universal Definition: Regardless of integration type, Process Time represents: "The time it takes for the service protected by NetFUNNEL to execute."
• Why This Metric Is Critical: NetFUNNEL doesn't directly monitor server internal state (CPU, memory, I/O). Process Time serves as an indirect indicator of:
  1. Server load state: Higher load → longer processing → increased Process Time
  2. User experience: Directly reflects how long users wait for service completion
  3. Capacity adjustment basis: Use Process Time trends to adjust Limited Inflow

Key Points:

• Real-time: Shows current average process time
• Statistics: Shows historical average process time (same calculation method as real-time)
• Indirect indicator of server load and performance
• If Process Time increases, server may be overloaded
• Used to optimize Timeout settings

Stage 6: Service Exit

Metric	Real-time Monitoring	Statistics	Unit
Outflow	Default: (not displayed) Classic: Outflow	(not shown)	TPS
Outflow Rate	Default: Outflow Rate Classic: Completion rate	Outflow Rate (%)	%

Outflow:

• Definition: Average number of explicit service exits per second, calculated as requests per second (TPS) within a specific time window, where only exits via nfStop() are counted
• Simple explanation: This shows how many users complete service and exit each second by explicitly returning their keys
• What it tells you: Enables you to assess integration quality and user behavior by comparing Outflow to Inflow—when they are close, users are completing normally; when Outflow is lower, it indicates session abandonment or integration issues
• Important Distinction: Outflow only counts explicit service exits where the service explicitly calls nfStop() (Code-based Integration) or the entry key is explicitly returned. Timeout-based exits, force-closed browser/app sessions, and network failures or connection drops are not included
• Why This Limitation Exists: By tracking only explicit exits, you can identify missing nfStop() calls, diagnose integration issues, and optimize Timeout settings
• Example Scenario: If Inflow is 100 TPS and Outflow is 50 TPS, this indicates that only half of entering users are explicitly exiting. You should immediately reduce Timeout to quickly free up capacity, and long-term investigate why nfStop() isn't being called properly

Outflow Analysis

If Outflow is significantly lower than Inflow, investigate:

• Are nfStop() calls missing in your code?
• Are timeouts too long, causing capacity to be held unnecessarily?
• Consider reducing Timeout values if explicit exits aren't happening

Outflow Rate:

• Definition: The percentage of users who entered the service and explicitly exited, calculated as (Outflow / Inflow × 100) within a specific time window
• Simple explanation: This shows what percentage of users who entered the service completed it normally by calling nfStop() and exiting
• What it tells you: Helps you evaluate integration quality—a high rate (close to 100%) indicates proper nfStop() implementation, while a low rate (<80%) suggests missing calls or integration issues that need attention
• Interpretation: 100% means all entering users explicitly exited, 50% means only half of entering users explicitly exited, lower values indicate missing explicit exits requiring investigation
• Operational Response: If you observe low Outflow Rate (<50-70%), high Queue Size, and high Wait Times, take these steps: immediately reduce Timeout values to free up capacity quickly, if queue remains long consider increasing Limited Inflow (if server resources allow), and long-term fix the root cause of missing nfStop() calls

Timeout Optimization

If your service typically completes in 1-2 seconds, but Timeout is set to 20 seconds (default maximum), adjust Timeout to 1-2 seconds to prevent unnecessary capacity holding.

Key Points:

• Only explicit exits (via nfStop()) are counted in Outflow
• Timeout exits are not counted in Outflow but do free capacity
• Low Outflow Rate (<80%) indicates missing nfStop() calls

Additional Metrics

Traffic Control Operations

Metric	Real-time Monitoring	Statistics	Unit
Bypass	(not shown)	Bypass	TPS
Block	(not shown)	Block	TPS

Bypass:

• Definition: Average number of users per second who enter the service directly without waiting, enabled through segment deactivation or project deactivation functionality, calculated as requests per second (TPS) within a specific time window
• Simple explanation: This shows how many users enter the service directly without going through the waiting room, typically due to segment or project deactivation
• What it tells you: Enables you to verify that bypass functionality is working correctly when segments or projects are deactivated, confirming that users can access the service without traffic control as intended

Block:

• Definition: Average rate of requests that received BLOCK responses per second. These are requests that were blocked from entering.
• Simple explanation: This shows how many users are blocked and sent to the Block Room when the segment's entry status is set to Block mode
• What it tells you: Enables you to verify that block functionality is working correctly, confirming that users are properly prevented from accessing the service when Block mode is enabled
• Note: Requests blocked by the Repeated Request Block feature (which return 302 status code) are NOT counted in this metric

NetFUNNEL Server-Level Metrics

Metric	Statistics	Unit
CPU Occupancy	CPU Occupancy (%)	%
All Requests (Server-Level)	All Requests	TPS
Session	Session	-
Block	Block	TPS

CPU Occupancy:

• Definition: CPU usage percentage at the time of measurement, displayed as a snapshot value
• Simple explanation: This shows what percentage of the NetFUNNEL server's CPU capacity is being used at the moment of measurement
• What it tells you: Enables you to assess NetFUNNEL server load status and identify potential performance issues, helping you determine if the NetFUNNEL server is under stress or has available capacity

Session:

• Definition: Count of completed sessions from service entry to service completion within a specific time window
• Simple explanation: This shows the total number of user sessions that started and completed successfully during the measurement period
• What it tells you: Helps you understand service usage patterns and completion rates, enabling you to assess overall service health and user engagement

All Requests (Server-Level):

• Definition: Average number of all API requests per second at the NetFUNNEL server level, including admin operations, data queries, and all other API calls, calculated within a specific time window
• Simple explanation: This shows the total number of requests that the NetFUNNEL server processes each second across all operations
• What it tells you: Enables server engineers to gauge the total system load, providing insight into the complete workload including all API calls and traffic control operations at the NetFUNNEL server level

Block:

• Definition: Average rate of requests that received BLOCK responses per second. These are requests that were blocked from entering.
• Simple explanation: This shows how many users are blocked and sent to the Block Room when the segment's entry status is set to Block mode
• What it tells you: Enables you to verify that block functionality is working correctly, confirming that users are properly prevented from accessing the service when Block mode is enabled
• Note: Requests blocked by the Repeated Request Block feature (which return 302 status code) are NOT counted in this metric