Design the TIE Server replication topology in favor of servers running in the Reputation Cache mode. You want to minimize servers running in the Secondary mode.

TIE Secondary servers allow scaling of the reputation services with low latency for all requests. Each Secondary instance connects to the TIE Primary Server and replicates back database changes using PostgreSQL Streaming Replication. Over-deploying Secondary servers increases the required bandwidth against the Primary server.

In addition, each non-reporting Secondary server connects remotely to the Primary server to push changes to the database. The Primary server must be able to handle remote connections from each Secondary server, which impacts its load and the total number of connections it can handle at one time. Cache misses and the first-time lookup also incurs a response time impact because the caching server defers to another (Primary or Secondary) TIE Server to resolve the lookup.

Rely on Reputation Caches to increase throughput of reused files on the environment without the need to spend bandwidth on database replication. For details, see KB89775 - How to configure Reputation Cache in TIE Server.

For assistance with further optimization opportunities, contact Technical Support.

• If you are a registered user, type your User ID and Password, and then click Log In.
• If you are not a registered user, click Register and complete the fields to have your password and instructions emailed to you.