-
-
Notifications
You must be signed in to change notification settings - Fork 271
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance: SMIME signatures slow down batch sending due to excessive keystore loading #320
Comments
(similar to #196, but for DKIM) |
I don't think caching is the solution, this functionality should simply operate on the right level (Mailer level that is), with overrides on a per Email basis (Email level). I'll be dedicating some time on this asap. You mentioned BouncyCastle is notoriously slow, can you provide some references for this? What would be an alternative? I'm not super familiar with security providers so this is new to me. |
…brary's performance issues (including BouncyCastle)
…mime properties are not set on Email anymore but on Mailer. S/MIME signing can be overridden on a per/Email basis. Consolidated all such properties (email validation criteria, S/MIME default signing, DKIM in the future as well) in new mailer level config object called EmailGovernance.
I've added both a simple cache and Mailer level S/MIME default signing option. This should completely resolve this issue. Haven't released it yet, as the wife is waiting with a crying baby for to join them :D priorities priorities... I'll release tomorrow (probably). I'll also update the documentation site then. |
Released in 6.6.0. For default S/MIME signing, you should now define S/MIME properties on the Mailer instead of the Email: |
When sending SMIME signed emails, we observe more than 85% of the send time is spent loading the keystore data provided in
Pkcs12Config
. On our somewhat dated infrastructure (Xeon E5-2670 with virtualization), this boils down to around 400ms of CPU time for every single email. This constrains the send rate on a dual-core virtual machine, regardless of number of executor threads (exceeding 2), to approximately 5 emails per second.In our case, we use the same signing key/certificate for every email in a batch (size ~200), so loading the keystore over and over is a waste of CPU time.
Key causes appear to be:
SmimeKeyStore
is loaded for every single mail, regardless of whether the same Pkcs12Config is reused.Would you be open to implementing keystore caching, or receiving a patch that implements that (either locally in Pkcs12Config or globally in SMIMESupport)?
The text was updated successfully, but these errors were encountered: