When you configure your FortiWeb appliance and its features, there are many settings and practices that can yield better performance.
^.*/index\.html$
/index.html
For example, when using auto-learning to discover if street addresses are a valid input, scanning for postal codes or state abbreviations instead may dramatically improve performance. A pattern to fully match all possible street addresses is significantly more complex, involving many more computations, and the most difficult addresses to verify might be complex enough to impact traffic throughput.
Short regular expressions can sometimes be more complex to compute. Don’t look at the number of characters in the regular expression. Instead, think of both the usual and worst possible case in the match string: the maximum number of characters that must be compared to the pattern before a match can be verified or not.
The usual case will tell you the average CPU and RAM load. The worst case will tell you if your regular expression could sometimes cause potential hang-like conditions, temporarily blocking traffic throughput until it finishes evaluating.
|
|
If the worst possible match string is short and not complex to match, the regular expression may not be worth your time to optimize. |
If missed matches are an acceptable performance trade-off (for example, if matching 99% of cases is efficient, but matching 100% of cases would require deep recursion), or if you do not need to match the whole text, remove the unnecessary part of the regular expression.
For example, if a phone number always resembles 555-5555, your regular expression would not have to accommodate cases where a space separates the numbers, or it is prefixed by a country code. This is less comprehensive, but also less CPU-intensive.
Avoid nested parentheses with indefinite repeats such as:
^((a+)b+)*
which can take a very long time to evaluate, especially if a long string does not match, but this cannot be determined until the very last character is evaluated.
In the above example, both the + and * indicate matches that repeat potentially infinitely, forcing the regular expression engine to continue until it finds the longest possible match (or runs out of RAM; see Killing system-intensive processes). Using both in a nested set of parentheses compounds the problem.
Minimize capture groups and back-references such as:
(/a)(/b)/(c)
$0$1\?user=$2
To use back-references, FortiWeb must keep the text that matched the capture groups in memory, which increases RAM consumption.
Order matters if using alternate match patterns (e.g., multiple patterns are concatenated with a pipe ( | ). Put rare patterns last. If you put less likely patterns first, most times FortiWeb will be evaluating the string multiple times—not once—before it finds a match. This significantly decreases performance.
When comparing single characters, use character classes such as:
[abc]
instead of alternative matches like
(a|b|c)
Match character by character, not word by word. If words begin with the same characters, it is not efficient to evaluate the beginning of the match string multiple times—once for each possible word.
For example, to match the words “the”, “then”, “this”, and “these”, this expression is easy to read, but inefficient because it evaluates the first two characters (“th”) up to 4 times:
\b(this|the|then|these)\b
While harder to read, this expression improves performance, evaluating “th” once, and will match the most common word in English (“the”) before considering less probable words:
\bth(e(n|se)|is)\b
Reduce nested quantifiers such as:
(abc)+
(abc){1,6}
Worst-case evaluations do not increase computation time linearly, but exponentially. When such an expression is compiled, it also consumes much more RAM. Use the smallest possible repetition, or an alternative expression.
/p{Nd} if you can use a character class instead. Due to the huge numbers and complexity of potential matches in Unicode, these can be dramatically slower.Avoid look-ahead match conditions such as:
?!abcdefge
?=abcdefge
To do this, FortiWeb must make additional computations—in the example above, 8 in the best case scenario, an immediate match. FortiWeb also must keep the originally consumed match string in memory while it does this, which increases RAM consumption.
Generating reports can be resource intensive. To avoid performance impacts, consider scheduling report generation during times with low traffic volume, such as at night and on weekends. For details, see Scheduling reports.
Keep in mind that most reports are based upon log messages. All caveats regarding log performance also apply.
When you configure a signature set as part of a web protection profile, consider limiting the scope and application of the Information Disclosure options. For details, see Information Disclosure.
The Information Disclosure feature can potentially require the FortiWeb appliance to rewrite the header of every request from a server, resulting in reduced performance. Fortinet recommends enabling this feature only to help you identify information disclosure through logging, and until you can reconfigure the server to omit such sensitive information.
From Web Protection > Web Anti-Defacement > Create New > Anti Defacement:
Vulnerability scan performance depends on the speed and reliability of your network. It also can be impacted by your configuration. For details, see Delay Between Each Request.
Packet capture can be useful for troubleshooting but can be resource intensive. To minimize the performance impact on your FortiWeb appliance, use packet capture only during periods of minimal traffic. Use a local console CLI connection rather than a Telnet or SSH CLI connection, and be sure to stop the command when you are finished. For details, see Packet capture.
FortiWeb allows you to tune TCP transmission performance by adjusting the buffer parameter of TCP connections through the CLI over high-bandwidth, high-latency networks. Large-size file transmissions (usually larger than 150MB) or serious traffic congestion between FortiWeb and backend servers is a common situation that might cause clients to experience poor TCP performance.
The tcp-buffer option in system network-option defines the TCP_mem variable to indicate to FortiWeb how the TCP stack should behave regarding memory usage. It consists of three values (the values are measured in memory pages):
Setting the tcp-buffer option as default, high, or max from the CLI specifies the three values to FortiWeb as following:
while tcp-buffer=default, (low, pressure, high) = (16384, 32768, 65536)
while tcp-buffer=high, (low, pressure, high) = (16384, 87380, 629145)
while tcp-buffer=max, (low, pressure, high) = (16384, 174760, 1258290)
Note that although the tcp-buffer option can provide an increase in throughput on high bandwidth networks, it decreases the number of concurrent TCP connections established on FortiWeb.
config system network-option
set tcp-buffer high
end