Optimising ADSS OCSP Server Performance

OCSP responders are used to provide timely information regarding the revocation status of a certificate compared with CRLs. In an environment where the number of OCSP transactions is very high e.g. above 500 requests per second, it may be advisable to tune the OCSP responder to minimise overheads.

The following guidance and optimization options are available - ask our Solution consultants for help with your specific requirements:

Use the fastest CPU available - ADSS Server is primarily CPU intensive, Xeon E3-xxxx or E5-xxxx or equivalent CPUs that are rated at 10K+ passmarks are recommended.
Use solid state disks instead of conventional spinning disks from the system. This will allow Signing Server to work efficiently on IO operations.
Ensure there is enough overall system memory and the "ADSS-service" Windows Service (or Unix daemon) has adequate memory assigned (min 4GB, consider 8GB for highest performance).
Use load balancing to distribute the OCSP requests across multiple ADSS OCSP Servers.
When using large CRLs or multiple CAs consider running the CRL Monitor module on a separate back end system (or two in primary/secondary mode)
This allows the front end systems to focus on handling OCSP requests and responses.
Check that the ADSS Server trace logs settings are set to the "Error" level and not "Info" and certainly not "Debug".
The transaction logging can be turned off altogether for OSCP Service - uncheck the log transaction settings field in OCSP Service Manager. However, if transaction log is still required:

Set appropriate parameters to carefully select and minimise the OCSP transaction details to be logged - see OCSP Service settings.
Check that lazy logging is being used and the settings are appropriate e.g. 5 4000 (write to the database every 5 seconds OR after 4000 transactions) - see ADSS Server Global Settings.

Local CRL caching should be enabled for all CAs being responded for - set within the Trust Manager module.
Consider storing certain CRLs in memory rather than in the database - set this within the Trust Manager module.
Use a suitably fast HSM to process the OCSP response signatures - PCIe HSMs can respond faster than networked HSMs.
Use a separate powerful database server over a suitably fast network - this allows all OCSP system resources to be dedicated to OCSP responding.
Avoid access control overheads and set access controls to allow all requests or at the very least don't use signed requests
Make these changes here: OCSP Service > Advance Settings > OCSP Request Handling
Only include a single CertID in an OCSP request.
Do not use a dynamic TLS channel between the OCSP client and the ADSS OCSP Server.
Consider using OCSP Repeaters for very fast local processing where a guaranteed connection to a central OCSP Server is not available.
Untick the checkbox 'Include responder's certificate in OCSP response' on OCSP Service > Register CA's screen, it will decrease the OCSP Response size and hence network latency as well.
Set Nonce = False in OCSP requests so that cached response can be returned.