Good afternoon,
I'm simulating a lab test, the objective is to verify the correct operation of the application in an environment with 20,000 PDF Workers each with its own certificate.
Test were made using nodb and mariadb, in both cases I get a new worker creation time of ~ 800 PdfSigners per hour. The greatest time consumption is observed in the commands to create and enable workers:
./bin/signserver setproperties myconfig / worker-pdfsigner {worker_id} .properties
./bin/signserver reload pdfsigner {worker_id}
Although the creation time of workers is quite slow, it would not be a problem since it would only be done in the initial setup.
The main problem is that with only 5000 PDF Signer Worker after a restart of the wildfly service, a delay of approximately 12 minutes is observed in the signer being functional again.
Is there an option that I can enable to improve the performance of the application that is not being applied or is it the expected performance of this software?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Additional Information
Software versions:
openjdk 11.0.8 2020-07-14
wildfly-14.0.1.Final
signserver-ce-5.2.0.Final
I only have 1 crypto worker with 1 single keystore with the 5000 certificates inside.
Each PDF Signer worker uses the same CryptoWorker with the assigned certificate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The slow creation of workers might be because the setproperties command applies each worker property one by one and each update is written to the storage and logged etc. The plan for the future is to apply all worker properties in a worker at a time to reduce this overhead.
I have also observed, especially the Workers page in AdminWeb to be slow to load with a larger number of workers (but I have not tested that large amount). I believe there is a lot of work being performed for each worker listed in order to check their configuration and even to do a test signature to see that the key matches and the algorithm is functional etc.
Many of this tests could probably be cached to speed up AdminWeb. However, in the situation you describe the delay happens on first use so that might not help.
Cheers,
Markus
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good afternoon,
I'm simulating a lab test, the objective is to verify the correct operation of the application in an environment with 20,000 PDF Workers each with its own certificate.
Test were made using nodb and mariadb, in both cases I get a new worker creation time of ~ 800 PdfSigners per hour. The greatest time consumption is observed in the commands to create and enable workers:
./bin/signserver setproperties myconfig / worker-pdfsigner {worker_id} .properties
./bin/signserver reload pdfsigner {worker_id}
Although the creation time of workers is quite slow, it would not be a problem since it would only be done in the initial setup.
The main problem is that with only 5000 PDF Signer Worker after a restart of the wildfly service, a delay of approximately 12 minutes is observed in the signer being functional again.
Is there an option that I can enable to improve the performance of the application that is not being applied or is it the expected performance of this software?
Additional Information
Software versions:
openjdk 11.0.8 2020-07-14
wildfly-14.0.1.Final
signserver-ce-5.2.0.Final
I only have 1 crypto worker with 1 single keystore with the 5000 certificates inside.
Each PDF Signer worker uses the same CryptoWorker with the assigned certificate.
Hi Frederico,
Interesting test!
The slow creation of workers might be because the setproperties command applies each worker property one by one and each update is written to the storage and logged etc. The plan for the future is to apply all worker properties in a worker at a time to reduce this overhead.
I have also observed, especially the Workers page in AdminWeb to be slow to load with a larger number of workers (but I have not tested that large amount). I believe there is a lot of work being performed for each worker listed in order to check their configuration and even to do a test signature to see that the key matches and the algorithm is functional etc.
Many of this tests could probably be cached to speed up AdminWeb. However, in the situation you describe the delay happens on first use so that might not help.
Cheers,
Markus