Performance: SMIME signatures slow down batch sending due to excessive keystore loading
bertm opened this issue · comments
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:
- A new
SmimeKeyStoreis loaded for every single mail, regardless of whether the same Pkcs12Config is reused. - The underlying implementation uses BouncyCastle to load the keystore, which is a notoriously slow provider.
Would you be open to implementing keystore caching, or receiving a patch that implements that (either locally in Pkcs12Config or globally in SMIMESupport)?
(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.
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:
