Data Loss Prevention Network Prevent for Web ICAP Performance Tuning


Article ID: 159666


Updated On:


Data Loss Prevention Network Prevent for Web


A summary of the tuning options available for Network Prevent for Web (ICAP).


DLP Network Prevent for Web (Web Prevent) ICAP performance is dependent on the number of CPU cores in the Web Prevent system, and on the performance of the proxy that feeds data to Web Prevent via ICAP.

The proxy server's performance includes two main limiting factors:

  • Maximum number of concurrent connections
  • Connection timeout

Here is a summary of the tuning options that are available, and how they interact with the performance of the Web Prevent system:

  • Number of cores available = Number of CPUs (sockets) x Number of Cores per CPU (socket)
  • MessageChain.NumChains = 1 x Number of cores available - note that previous recommendations for 2x Number of cores may not be advisable in virtual server environments
  • MessageChain.CacheSize = Same value for MessageChain.NumChains
  • Maximum Number of Requests: Specifies the maximum number of simultaneous ICAP request connections from the HTTP proxy or proxies. The default is 25.
  • Connection Backlog: Specifies the maximum number of waiting connections allowed. Each waiting connection means that a user waits at their browser. The minimum value is 1.

For tuning purposes, a MessageChain is a single complete detection engine pipeline, which examines the content sent by the ICAP proxy server. The baseline recommendation is that the maximum number of requests should be set to twice the value of MessageChain.NumChains, as determined by the hardware specifications of the server based on the above guidelines. This number can be adjusted based on system load.

It is very important to match or exceed the proxy server's maximum number of concurrent ICAP connections to the Web Prevent's setting ("Maximum Number of Requests" in the user interface). If the proxy tries to send more connections than the Web Prevent server is configured to accept, this will result in either a service interruption (i.e. "503 Server overloaded" error)* or a "fail open" scenario in which some traffic passes without being examined by DLP.

The primary constraint on ICAP Prevent performance is the memory limitations of the Java Virtual Machine (JVM). Although previous 32-bit JVM maximum addressable memory restrictions no longer apply in 64-bit systems, it's still possible to exceed the Java Heap. For more information on DLP memory usage and how to resolve issues, see How to address out of memory errors ( OOM ). There is a further requirement for a contiguous block of memory for Java heap space, which is allocated at startup. In practice, based on the default allocation to the BoxMonitor.FileReaderMemory in DLP, the effective size of a single contiguous block of memory is approximately 1.3GB.

For best practices and methodology of tuning prevent servers, please see the guides at this page: Symantec™ Data Loss Prevention Network Monitor and Prevent Performance Sizing Guidelines (

*With the default settings, Web Prevent will handle a maximum of 25 active requests and may buffer up to 30MB of content in memory for each request. This accounts for about 750MB of Java heap space (memory usage). The default settings are adequate to allow additional headroom for other functions and may be adjusted based on the observed load in the environment and performance of each server. For more information on this specific topic, see Web Prevent Returning "503 Service Overloaded" to Upstream ICAP Client (