Good practices

Reuse sessions (benefit from session caching). Use the HSM session cache and gain performance by reusing HSM and HTTP sessions. In this case, it is recommended that you open a session, perform the operations you want and then close it, allowing the session to be reused quickly, thus reducing downtime.
Ensure that sessions are closed. Closing sessions guarantees the release of the resource, both in the HSM and on the client. Make sure that sessions are closed even for operations with a return code other than success.
Use concurrent sessions. Using concurrent/parallel sessions with the HSM helps to extract maximum performance. Attention should be paid to using too many sessions with HSMs, so as not to cause unnecessary use of resources. The throughput curve tends to rise and find a plateau.

Define a connection object reload interval. You can optimize the number of times HSM keys and objects are loaded by setting a reload interval for HSM objects. As the institution's key/certificate/chain update is done infrequently and on a scheduled basis, it is advantageous to define a reload interval for these objects. Pay attention to network asset timeouts that are shorter than this value to avoid premature disconnections and unnecessary errors.

See more details and how to configure in the env vars topic.

Set the HSM connection timeouts. When the HSM timeout is not set, the default is that of the operating system. In the event of a connection failure, the application may wait too long. It is important to ALWAYS set the HSM send and receive timeouts (see the topic env vars). Other connection parameters can also be configured.

Define the HTTP operation timeouts. When not defined, the default HTTP operation timeout is unlimited. In the event of an HTTP connection failure, the application may be put on hold indefinitely. It is important to ALWAYS set the timeout in HTTP request calls.