Audits in the API Gateway and Performance

Products

• CA API Gateway

Issue/Introduction

What are the repercussions of using Audits within the CA API Gateway?

Resolution

Auditing is Very Expensive
Use auditing sparingly, as it can impact Gateway performance, sometimes significantly.

During the development/testing phase, detailed audits can help you identify and resolve problem points. However when the policy is moved to production, remove all unnecessary audits to maximize Gateway performance. It is strongly recommended against using the audit subsystem unless mandated by regulatory agencies.

Audits are a useful tool for policy development, but is a detriment to production as the INFO level will generate many audits.

You should delete all instances of the Audit Messages in Policy Assertion for production policies, except for noting errors and debug situations. They should never be used as part of normal policy flow. Ideally, a production policy should produce no audits at all during successful execution.

Logging is Cheaper, But Not Free
In the Add Audit Details Properties, you can opt to Log transactions rather than audit them. This causes the Gateway to capture the data in a log file rather than initiating a database transaction. This is less "expensive" than auditing as it requires less overhead.
Logs lacks the structure and viewing user experience of our audit viewer, but they do not have the database transaction limitations. 

 

But it is recommended in all cases especially in a PERFORMANCE situation that AUDITS not be used unless required. And if you do require audits that if all possible you log to logger, which then can be offboxed.