In the last weeks I have been asked again and again how I can increase the performance of my Check Point gateway. Now comes my counter-question. What do you want to reach in Performance Tuning?
Therefore, I have created an overview of what the goal is!
Moe interesting articles:
- R80.x Architecture and Performance Tuning - Link Collection
- Article list (Heiko Ankenbrand)
In principle, there are several performance metrics:
- Throughput (Bandwidth)
- Connection rate
- Packet rate
- Concurrent connections
- Latency
There are standardized test procedures according to RFC for this:
| |
Throughput
|
Connection rate
|
Packet rate
|
Concurrent connections
|
Latency
|
|
RFC
|
RFC3511 5.1.4.1
|
RFC3511 5.3.1
|
RFC3511 5.1.4.1
|
RFC3511 5.2.4.2
|
RFC2544 26.2
|
|
Units
|
Bit/s
|
Connections/s
|
Packets/s
|
Absolute number of connections
|
(m)s
|
|
Testing conditions
|
Large UDP
|
Small TCP
|
Small UDP
|
Small TCP
|
Small UDP
|
|
Bottleneck
|
Bus, Interfaces
|
CPU
|
CPU
|
Memory
|
Bus, Interfaces, CPU, Infrastructure
|
Description: RFC3511 – 5.1.4.1
Throughput: Maximum offered load, expressed in either bits per second or packets per second, at which no packet loss is detected. The bits to be counted are in the IP packet (header plus payload); other fields, such as link-layer headers and trailers, MUST NOT be included in the measurement.
Units: Bits per second
Testing conditions for achieving best results: Large UDP
Bottleneck: Bus, interfaces
Description: RFC3511 – 5.3.1
To determine the maximum TCP connection establishment rate through or with the DUT/SUT, as defined by RFC 2647 [1]. This test is intended to find the maximum rate the DUT/SUT can update its connection table.
Units: Connections per second
Testing conditions for achieving best results: Small TCP (HTTP 64B)
Bottleneck: CPU
Description: RFC3511 – 5.1.4.1
Throughput: Maximum offered load, expressed in either bits per second or packets per second, at which no packet loss is detected. The bits to be counted are in the IP packet (header plus payload); other fields, such as link-layer headers and trailers, MUST NOT be included in the measurement.
Units: Packets per second
Testing conditions for achieving best results: Small UDP
Bottleneck: CPU
Description: RFC3511 – 5.2.4.2
Maximum concurrent connections: Total number of TCP connections open for the last successful iteration performed in the search algorithm.
Units: Absolute number (amount)
Testing conditions for achieving best results: Small TCP (HTTP 64B)
Bottleneck: Memory
Description: RFC2544 – 26.2
The latency is timestamp B minus timestamp A as per the relevant definition from RFC 1242, namely latency as defined for store and forward devices or latency as defined for bit forwarding devices.
Units: (m)seconds
Testing conditions for achieving best results: Small UDP
Bottleneck: Interfaces, Infrastructure, CPU, Bus
The analysis of the above mentioned parameters is very easy with the command cpview.
# cpview
On 41K, 44K, 61K, 64K or Maestro systems use:
# asg perf -v
➜ CCSM Elite, CCME, CCTE
