Open Teka0w opened 1 year ago
Hi @Teka0w
please test this using the latest 6.4.x (where SMIME handling especially the storage and lookup up is improved) or the upcoming 6.5.x
The problem is, in the most cases, not the Decryption but the lookup behaviour of the old version. I assume when you open the "Answer" screen it is also pretty slow?
An additional question: Do you use: PostMaster::PreFilterModule###000-DecryptBody ?
regards Johannes
Hello @hanneshal, thank you for your fast reply.
Indeed I meant not Decryption but the lookup behavior, thanks for correcting me.
I was looking into SMIME handling from newer releases, do you mean the added indexes for SMIME certificates? If you could provide some information or something to read would be nice. Will be testing 6.5.1 next, but takes some time to update the packages our organization accumulated over the years.
The "Answer" screen takes about 1-2 sec to open on a ~20 sec loading time ticket, so it seems fairly fast.
We don't use PostMaster::PreFilterModule###000-DecryptBody, but I tried it on our test instance and it doesn't change the behavior, as the issue lies within SMIME handling, not decryption. Sorry for the miscommunication.
P.S.: I ran above described tests with emails sent from user to znuny-queue.
Thanks for your time and looking into this matter.
regards Ewald
Hi,
the old mechanism (before 6.4.) was just a file lookup. This happened every time, because nothing relevant was stored in the DB. So if the keystore is large, it takes more time. This is IMHO still the way all the other forks handle this.
We changed this in 6.4. and store all relevant information, to perform a lookup, in a separate and new table. So a major rework of the whole store and lookup logic. There is a separate migration step for 6.4 and a new daemon task for reindexing. Which should improve the performance by a lot.
Regards Johannes
Hi @hanneshal,
i upgraded to 6.4.4 and and tested it again, doesn't seem to change anything on loading time from tickets. Only the "AgentTicketQueue" seems to be a little bit faster.
Would be nice if you could look into the SMIME behaviour again for further improvements.
Regards Ewald
Hi @hanneshal,
small update: migrated from Znuny 6.0.48 to OTOBO 10.1.7 to test above mentioned feature of OTOBO. Test ticket loading time is about half in comparison from OTOBO 10.1.7 (~5s) to Znuny 6.5.1 (~12s). Tested on test-system with no traffic, prod loading times will be longer, as seen before (~130 concurrent agents/users).
Test setup: Used Znuny 6.0.48 database dump with test ticket for each Znuny 6.5.1 OTOBO 10.1.7 to create equal test condition in migration and ticket loading time.
Can provide more information if needed.
Regards Ewald
Hi @Teka0w
thanks for the update. We already had a look into this earlier. The advantage is achieved by the fact that the sign / crpyt results are stored on the ticket or article. There is no live check anymore. We still need to decide if this is acceptable for us or not. Because the impact is not just a speedup but also a change in behaviour for signed and crypted mails. Which is, at least in some environments, not wanted at all.
Side question: Which article view do you use? Show all articles or single article?
Above mentioned tests used "Show all articles" as worst case.
tested just now with "single article", Znuny is at (5sec +/-1sec) and OTOBO is at (3sec +/-1sec).
Is an okay workaround for "AgentTicketZoom", but its hard to enforce "show single article" to users, wich had "show all articles" for 10+ years. Problem also occurs on "AgentTicketQueue", but depends on number of shown tickets and size of View (S,M,L, - S is the fastest). Can be annoying because of the refresh every 2 minutes. Workaround here is to use AgentDashboard, which isn't effected of this slow down.
Environment
Expected behaviour
With increasing use of SMIME signed emails there should be a modern/better way for SMIME decryption. In Znuny SMIME decryption happens on every call of "AgentTicketZoom" (maybe on "CustomerTicketZoom" too, we don't use customer logins). After some digging I found a solution from OTOBO, in which they changed decryption to happen at receipt of email.
See here https://github.com/RotherOSS/otobo/issues/1419
Actual behaviour
SMIME decryption happens on every call of "AgentTicketZoom" and to a lesser content on "AgentTicketQueue". This causes very big slow downs of loading times for each ticket with many SMIME signed articles. With around 600 new daily tickets and increasing loading times to around 20 sec makes Znuny nearly unusable.
How to reproduce
Steps to reproduce the behavior:
Additional information
Not sure if security related, SMIME encryption works, its just really slow.
Screenshots
None.