Policy engines can process events such as emails or files arriving from an external source and apply policy triggers to these events. Typically, events are allocated to individual policy engines by a policy engine hub. Policy engines enable CA Data Protection to integrate directly with :
CA Data Protection 14.x\15.x
Physical verses Virtual.
There is a drive towards virtualization as this can reduce the total cost of ownership (TCO) by making it quicker and easier to commission machines, however the CA Data Protection Policy Engines are designed to enable maximum use of the physical CPU and that performance could be constrained in a virtual environment. To clarify, CA Data protection Policy Engines do run on virtual platofrms, but performance is improved by having a dedicated CPU rather than running on a VM host where Data Protection PEs only get a slice of the core and share it with other processes.
Maximum Number of Concurrent Operations
The "Maximum Number of Concurrent Operations" machine policy setting can be configured to define the maximum number of emails that can be processed simultaneously. This defaults to 5. and it enables the policy engine to make the most efficient use of system resources.
You may want to increase the maximum limit if the policy engine is running on a multiprocessor computer.
If this maximum limit is reached, the policy engine delays accepting any further emails from the policy engine hub until the number of emails being processed falls below this maximum limit. This means that when an email completes processing, another is accepted, so maintaining the number of emails at the maximum limit. For example, if five emails finish processing simultaneously, the policy engine immediately accepts five new emails.
If your system has at least 1x 16-core double-threaded chip and that the core(s) is(are) fully dedicated to the PE function (ie this is not a VM host on which the PE is running as a guest) you could set the conncurrency value to 32.
If you had, for example an Intel Xeon E7-4850-v4 processor which has 16 cores and 32 threads, you could set the concurrency to a value of 32 for PE concurrency and this will create 32 processing threads on the PE. However, because this processor has two threads per core, it may be possible to set the concurrency to 48. Higher setting are possible but we would recommend exhaustive testing to see if there is any significant performance improvement or instability.
In addition to the number of physical cores, the other limitation is the amount of Memory. Each PE Processing thread requires an amount of RAM. If we were to assume each thread requires 1MB per thread, you would need at least 32 GB of Memory to support the 32 threads concurrently.
Note: The figures above are only illustrative and represnt virtual memory and not necessarily physical. This means that the SWAP / PAGE file should be located on fast I/O storage.
Policy Engine Scaling
While planning your PE deployment you should consider scaling and IO performance.
As far as the storage on the PE is concerned you need to consider the follwoing things:
1. Is the PE using a local SQL database instance? If it is, the storage should be configured as per the client’s SQL Server Storage configuration standards / best practice. This typically means that the PE will have at least 4 volumes – each on dedicated spindles (not separate partitions on the same disk). For example:
Optimizing PE performance needs to consider a large number of variables specific to each customer environment. While this knowledge document offers some areas for consideration, however refining performance may require testing in a controlled environment. CA Services can assist with Policy Engine refinement and testing as a billable service. To engage with CA Services please reach out to your CA Account Manager.
CA DataMinder, CA DLP, Orchestria, Orchestria APM and Orchestria EPM are all previous brands for the product now known as CA Data Protection.