Frontend Number of New Sessions /s

What Is the Frontend Number of New Sessions /s Condition?

Frontend Number of New Sessions /s is a condition type used to make traffic routing and manipulation decisions by evaluating the number of new sessions per second coming to the vService (frontend).

vService · web-frontend

New sessions (TCP)135Sessions / s

With this condition, dynamic decisions can be made according to instantaneous changes in traffic density.

Comparison of Similar Conditions:

Metric	Checked Information	Usage
Frontend Number of New Sessions /s	New sessions per second	Traffic flow rate
Frontend Connection	Total active connections	Instantaneous load
Frontend Number of HTTP Requests /s	HTTP requests per second	HTTP traffic density

TIP

Session vs Connection

• Session: Establishment of the TCP connection (3-way handshake completed)
• Connection: Number of active connections

Session rate shows the flow of new connections; connection shows the total active connections.

The Importance of the Frontend Number of New Sessions /s Condition

The session rate is a critical metric that shows the instantaneous traffic density the system is exposed to.

With the Frontend Number of New Sessions /s condition:

• Sudden traffic spikes can be detected,
• DDoS attacks can be detected at an early stage,
• Dynamic rate limiting can be applied according to traffic density,
• Different traffic policies can be applied during peak hours,
• Measures can be taken before the system capacity is exceeded.

Supported vService Types

HTTP

L7 TCP

Network

The condition can be used only at the request (At Request) stage. The rate is read from the engine's internal counter as the number of new sessions accepted per second by the related vService; there is no configurable measurement window on the TR7 side.

How to Add?

A new Frontend Number of New Sessions /s Condition can be added through the TR7 web management interface by following the steps below:

1. The Configuration Menu is opened by clicking the TR7 logo at the bottom left.
2. The Load Balancer → Conditions → Add steps are followed.
3. Frontend number of new sessions/s is selected as Criteria.
4. The related configurations of the condition are made.
5. The condition is added by clicking the Add button.

Frontend Number of New Sessions /s Condition Add Form

Frontend Number of New Sessions /s Condition Add Form

INFO

Condition Name

An optional name can be entered for the condition to be created.

This field is especially important in the following scenarios:

• When many conditions are defined under the same vService,
• When conditions with similar criteria need to be distinguished,
• When it is necessary to quickly understand which business rule the condition represents.

When this field is left empty, TR7 analyzes the content of the related condition and creates an automatic, descriptive name in the Condition Description field. This generated description is used as the name in condition lists.

INFO

Criteria Required

The field that determines the type of the condition; Frontend number of new sessions/s is selected from the searchable dropdown list. This selection determines the fields displayed in the form. The criterion cannot be changed after the condition is saved: if a different criterion is needed, a new condition is defined. For all criteria in the list and their scopes, the criteria catalog on the Conditions page can be referred to.

INFO

Operator

The numeric comparison operator and value are entered. The form opens with the operator Equals to (=) selected and the value empty; the entered value must be an integer.

Operator	Symbol	Description
Less than	<	The value must be less
Equals to	=	The value must match exactly
Greater than	>	The value must be greater
Range	-	The value must be between two values; when selected, a second value field opens; both boundaries are included in the range

TIP

The instantaneous session rate can be used in actions with the Sessions per second smart variable (e.g. as the value of an HTTP header or a log field).

TIP

Baseline values should be determined by monitoring normal traffic patterns. Sudden increases can usually be a sign of an attack or viral content.

INFO

Condition Description

It is created automatically by TR7 in line with the entered criteria and values.

This description:

• which value the condition applies to,
• which criterion it works on,
• the quick understanding of the condition on listing screens

is produced dynamically by the system so as to provide these.

INFO

Form Buttons

Add

The condition adding process is completed by clicking the Add button.

Add & Repeat

With the Add & Repeat button, the condition adding process is completed, and another new condition can be added with different configurations without leaving the related window.

Condition Added

Operational Usage Recommendations

• It Should Be Used for Spike Detection. Conditions should be defined for values above 2-3 times the normal traffic baseline.
• DDoS Early Warning. An abnormally high session rate can be an indicator of a SYN flood attack.
• Combinations Should Be Used. A more accurate traffic analysis should be performed by using session rate and connection count conditions together.
• It Should Be Integrated with Monitoring. Session rate metrics should be integrated with monitoring systems.

Common Usage Scenarios in Live Environments

The examples below show how the related condition is applied in the most frequently encountered use cases in real systems. These scenarios are based on practices that are widely preferred in live environments and rest on experience gained in the field.

Scenario 1: SYN Flood Attack Detection and Protection

Purpose: To detect a SYN flood attack when an abnormally high number of new sessions (TCP SYN) per second comes to the vService, take automatic protection measures and protect the connection capacity.

Configuration: Operator → Greater than (>) 2000

Action Recommendations:

• ✅ Block → New connections above 2000 session/s are blocked; 503 Service Unavailable can be selected as the response code (default 403 Forbidden). The SYN flood is stopped.

Scenario 2: Traffic Spike Detection and Warning

Purpose: To detect a sudden traffic increase above the normal baseline, inform users and warn system administrators.

Configuration: Operator → Range (-) 500-2000

Action Recommendations:

• ✅ Show Content → The warning page "Congestion detected in the system, please wait" is shown; traffic that goes above the band is caught by the blocking in Scenario 1.
• ✅ Add HTTP Header → The X-Traffic-Spike: detected header and the X-Session-Rate header, whose value is bound via fx to the Sessions per second smart variable, are added; the traffic increase is marked together with its instantaneous rate.
• ✅ Advanced Traffic Inspection → Traffic increase events, timestamps and baseline deviation rates are reported.

Scenario 3: Abnormal Traffic Drop Detection

Purpose: To detect and mark early an abnormal drop in the session rate in a vService where continuously high traffic is expected (e.g. a DNS problem, an upstream outage, a publication/announcement error).

Configuration: Operator → Less than (<) 50

Action Recommendations:

• ✅ Add HTTP Header → The X-Low-Traffic: true header is added; monitoring systems generate alarms based on this marker.
• ✅ Advanced Traffic Inspection → Low traffic periods, their durations and the baseline deviation are reported.