15.15. Performance considerations

You can test performance using the apache bench from the apache utils. Creating a simple pass token for a user, eases the performance testing.

Then you can run:

ab -l -n 200 -c 8 -s 30 'https://localhost/validate/check?user=yourUser&pass=yourPassword'

The performance depends on several aspects like the connection speed to your database and the connection speed to your user stores.

15.15.1. Processes

You should run several processes and threads. You might start with the number of processes equal to the number of your CPU cores. But you should evaluate, which is the best number of processes to get the highest performance.

15.15.2. Config caching

eduMFA uses a Cache per instance and process to cache system configuration, resolver, realm and policies.

As the configuration might have been changed in the database by another process or another instance, eduMFA compares a cache timestamp with the timestamp in the database. Thus at the beginning of the request eduMFA reads the timestamp from the database.

You can configure how often the timestamp should be read using the edumfa.cfg variable EDUMFA_CHECK_RELOAD_CONFIG. You can set this to seconds. If you use this config value to set values higher than 0, you will improve your performance. But: other processes or instances will learn later about configuration changes which might lead to unexpected behavior.

15.15.3. Cryptography

Cryptography, especially Public-key cryptography is typically based on solving difficult and/or time-consuming problems. eduMFA uses a lot of cryptographic techniques to ensure the security of its operation.

Some cryptographic operations are not strictly necessary for the secure operation but provide additional safety for the user. If performance is an issue, some of these can be disabled to improve the throughput.

Please also read Cryptographic considerations of eduMFA to understand the implications.

15.15.3.1. The Audit-log

Each entry in the Audit log is digitally signed to detect tampering. If you can be sure that the private key in EDUMFA_AUDIT_KEY_PRIVATE has not been tampered with, you can set the config entry EDUMFA_AUDIT_NO_PRIVATE_KEY_CHECK = True in The Config File to improve the performance when loading the key.

With the config entry EDUMFA_AUDIT_NO_SIGN = True the signing of the Audit-log can be deactivated completely.

15.15.3.2. The eduMFA Response

By default, eduMFA signs every JSON-Response with the private key in EDUMFA_AUDIT_KEY_PRIVATE. To improve the performance when loading the private key the config entry EDUMFA_RESPONSE_NO_PRIVATE_KEY_CHECK can be set to True.

The signing of the response can be disabled completely by setting EDUMFA_NO_RESPONSE_SIGN to True.

15.15.4. Logging

Choose a logging level like WARNING or ERROR. Setting the logging level to INFO or DEBUG will produce much log output and lead to a decrease in performance.

15.15.5. Response

You can strip the authentication response to get a slight increase in performance by using the policy no_details_on_success.

15.15.6. Clean configuration

Remove unused resolvers and policies. Have a realm with several resolvers is a bit slower than one realm with one resolver. Finding the user in the first resolver is faster than in the last resolver. Although e.g. the LDAP resolver utilizes caching.

Also see What happens in the tokenview?.