Does the WAF slow down my site?
Short answer
The WAF adds a processing time to the request; what mainly determines this time is not the number of signatures but the request itself (performance). TR7 WAF is not a separate device or an additional network hop; it runs inside the vService. The signatures are kept in precompiled databases and every value of the request is scanned against these databases; for this reason, adding signatures does not grow the time in proportion to the number of signatures. What grows the time is the amount of data scanned: the number of parameters, the size of the body and the JSON or XML depth. There are two behaviors to know: to inspect the body, the WAF by default waits for the whole body (or for the buffer to fill up) and the request is forwarded to the Backend Service after this (Wait for Body for a Time); in Blocking Mode, a request whose scan cannot be completed within the 2-second time limit is blocked (if Fail-open in the Request Body Limits window is on, it is let through without being scanned). Requests treated as static with Do Not WAF Static Contents and requests that match the Whitelist Condition do not enter the inspection at all. The actual time is read from the WAF Time field in the Event Logs records and from the time distribution in the Traffic view of WAF Report; it exists only in requests written to Event Logs.
What Determines the Time
| Factor | Effect | Details |
|---|---|---|
| Number of signatures | Not proportional; the signatures are in compiled databases | Does latency grow as the number of rules grows? |
| Body size and type | Waiting, parsing, scanning and memory | How do large request bodies (file uploads) affect WAF performance? |
| Static content, Whitelist Condition | Does not enter the inspection | What does excluding static content from inspection gain in performance? |
| Learning Log | Write cost only on the traffic within the learning scope | How are the disk and CPU load of the learning log kept under control (Smart Sampling)? |
| Heavy traffic | Capacity limited by the cores and memory allocated to the vService | How does WAF inspection behave under heavy traffic? |
| 2-second scan limit | If it is exceeded in Blocking Mode, the request is blocked; if Fail-open is on, it is let through without being scanned | What happens to a request if the scan exceeds a certain time (2-second scan limit)? |
- The WAF inspects the request before the Load Balancer actions (Actions) (Which stages does a request go through inside TR7 before it reaches the backend?).
- Measurement: How do I measure the time the WAF adds to a request; for which requests is it visible? · Meaning of the value: What exactly does the WAF Time value measure?
- Separate cores and memory are allocated to critical vServices with QoS (What is QoS; how do I reserve dedicated CPU/memory resources for critical vServices?).
Common Misconceptions
- "Every new signature slows down every request a little more." The signatures are scanned together in compiled databases; the time does not grow in proportion to the number of signatures.
- "WAF Time is the total extra time the user waits." The time spent waiting for the body to arrive from the network is not included in the WAF Time value.
- "The WAF time of clean requests is also seen in Event Logs." The time exists only in requests written to Event Logs.
How it is done in the documentation
