Idea ID: 1646458

Smart Email causes critical performance issue

Status : Waiting for Votes
over 3 years ago

We've installed Service Manager 9.50 and configured smart email. The tokens of the Smart Email causes saving times of ticket up to 1500% (15 times) higher than without Smart Email Tokens. Saving times without Email Integration are approx 1 second. Using Smart Email Integration the saving times are sometimes higher than 15 seconds.

This is caused by tokens that has been configured into the email html templates. This email will be sent to the assignment group of the ticket, when the ticket will be assigned to this group. The Smart Email Token causes that the Emails will be separated and each member of the Assignment group will receive a individual email containing an individualized token in the email body. This leads to the fact that service manager sends 100 emails when the assignment group contains 100 members. And then the saving of the ticket takes more than 15 seconds.

Suggested fix: In my opinion the smart email tokens should not cause the separation of the emails. At the moment a token can only be stored for one recipient. To solve these performance issues, the token should be stored for all recipients of the email.

Example 1:
Email will be sent to recipient1, recipient2 & recipient 3:
Tokens of email 1 look like this:
unique.key=SD10202&file.name=incidents&name=Service Catalog Approval&component=null&_file=Approval&_ recipient=recipient1@hpe.com&_action=approve&_time=1461657364448

Tokens of email 2 look like this:
unique.key=SD10202&file.name=incidents&name=Service Catalog Approval&component=null&_file=Approval&_ recipient=recipient2@hpe.com&_action=approve&_time=1461657364448

and so on...

Example 2:
Example 1:
Email will be sent to recipient1, recipient2 & recipient 3:
Tokens of email 1 look like this:
unique.key=SD10202&file.name=incidents&name=Service Catalog Approval&component=null&_file=Approval&_ recipient=recipient1@hpe.com;recipient2@hpe.com;recipient3@hpe.com&_action=approve&_time=1461657364448

=> Therefore only one Email will be sent instead of 100 (or more)...

Workarounds have been provided on QCIM1E141852, but these are unacceptable

  • Sending email performance is a general issue. Or let's say it more precisely: The response time to the user.

    Hence I'd like vote for this - even my concrete experience is not Smart Email of tokenization.

     

    My recent expirience here is for SM 9.41 (not Smart Email):

    A custom "Send HTML email" rule is used to send notification of incident being generated from interaction to all members of the assignment group. If the assignment group has up many members, response time increases up to 10 seconds.

    Trace analysis shows that mailer RAD application is called in foreground for each receiver name separately and selects operator record to lookup the email. This select may take 100ms only - but it sums up for 30 or more receivers.

    There are two ways to make situation better - and you can combine them:

      - efficiency: Move select (query: "name=\""+str($mai in $musrs)+"\"" ) from inside the loop in RAD mailer outside and just loop over result list of query "name isin "+str($musrs)

      - response time reduction: Make "Send HTML email" rule just add schedule record that than is executed by background process.

  • Workarounds have been proposed but rejected by the customer. An alternative approach was suggested:

    The problem is, that the email is split into multiple email. This causes, that many emails has to be processed instead of one. The reason why this has been implemented this way is that a token contains the email address of the recipient. Furthermore the token is not able to store multiple email addresses, if the email would be sent to multiple recipients.
    This should be redesigned. A Smart Email Token should be able to store multiple Email Addresses. Therefore an array of email addresses has to be added to the tokenstore. If an incoming email contains this token, service manager should check if the senders email address is in the recipients email address array of the previously saved token. This means only one token has to be stored and only one email has to be sent. Which will lead to the expected performance of the system.

    Please check the proposal and give us a feedback.