search

znuny / znuny-feature-requests

This repository tracks feature requests as issues.
7 stars 1 forks source link

Feature - SMIME handling causes extreme slowdowns #46

Open Teka0w opened 1 year ago

Teka0w commented 1 year ago

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:

  1. Create ticket with many articles, around 20.
  2. Track loading time of ticket via F12&NetworkTab. ~2 sec
  3. Create new test ticket with many articles with email from SMIME user.
  4. Track Loading time of SMIME ticket, see difference with about ~20 sec.

Additional information

Not sure if security related, SMIME encryption works, its just really slow.

Screenshots

None.

hanneshal commented 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

Teka0w commented 1 year ago

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

hanneshal commented 1 year ago

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

Teka0w commented 1 year ago

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

Teka0w commented 1 year ago

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

hanneshal commented 1 year ago

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?

Teka0w commented 1 year ago

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.