slow response after upgrade

[snifty]

I upgraded from 2.7.6 to 2.8.2 on friday and since that hesk is working much slower.
When replying to a ticket as an admin it takes about 5 seconds to get a response.
When a user creates a new ticket ist takes about 10 seconds to get the spam notification displayed.
In both cases I see that the httpd.exe goes up highly on the server.
Actually i do get the email before the Website is reloaded.

Any ideas what changed that could cause the problem or what I could look at to trace the problem more detailed?

Thank you!

[snifty]

BTW: Is it intended that the new feature "bulk assign tickets form the ticket list" shows all users (not only the one in the same category) in the "Assign selected to" Dropdown, or ist this a bug?

[Klemen]

Nothing changed in 2.7.6 => 2.8.2 that would cause a delay.

My guess is the delay is caused by sending emails - is Hesk connecting to an external SMTP server?

Yes, all users are shown below the bulk assign to, because the list of tickets can include tickets from mixed categories. If the user doesn't have access to a ticket, that ticket is not assigned and a warning is shown.

[snifty]

Yes you are right!
When I reply to a ticket without sending email notification of this reply to the customer everything works smoothly as before.
When I reply with a notification (default) it takes more than 10 seconds, and the httpd climbs up until I see the site again.

I'm using the internal php mail (and no piping or pop3/imap-Fetching).
Any hints what can be wrong here?



Ok, I tried moving a ticked to sombody in another category and a warning is shown. Perfect!

[snifty]

I figured out that the creation of the Message-ID header is the problem.

When I remove line 306 and 340 (the ones where the function hesk_generateMessageID is used) in email_functions.inc.php everything works in normal speed again.

For what exactly is the unique Message-ID header in outgoing emails needed? For better tracking/logging purposes in php_mail.log only or does it have any other aim?


But the log in php_mail.log it self Looks good:
mail() on [\hesk\inc\email_functions.inc.php:311]: To: dhm@hxxxxl.at -- Headers: From: Help Desk <noreply@hxxxxl.at> Reply-To: Help Desk <noreply@hxxxxl.at> Return-Path: administrator@hxxxxl.at Date: Tue, 31 Jul 2018 09:15:29 +0200 Message-ID: <qi6yx3v1ckgk.20180731071620@web.hxxxxl.at> Content-Type: text/plain; charset=UTF-8

It seems that openssl_random_pseudo_bytes stresses my host in some way because if I try the first example here
http://php.net/manual/en/function.opens ... -bytes.php
my CPU also goes up very high until the operation is finished.

Must be a problem of my php version (yes, I feel ashamed my version 5.3.1 is pretty old):
http://php.net/manual/en/function.opens ... php#101795

[Klemen]

I'm glad to see you figured out what is causing the problem.

Message ID is not used within HESK; it's there because it's required by standards and some SPAM filters treat a missing message ID as a negative spam score (more likely to block email).

For the above reason I would keep the Message ID in your emails and instead change this in inc/email_functions.inc.php

Code: Select all

$id = base_convert(bin2hex(openssl_random_pseudo_bytes(8)), 16, 36);

to

Code: Select all

$id = uniqid('', true);

And you really should update your PHP (and related software); if you for some reason rely on 5.3.x at least get 5.3.29

[snifty]

Klemen, thank you for you super fast help!

I now did it the way you recommended.
But in our case The Message ID isn't relevant because we use hesk just internally.

It seems it is a bug in PHP < 5.3.4:
"Fixed possible blocking behavior in openssl_random_pseudo_bytes on Windows. (Pierre)"
http://php.net/ChangeLog-5.php#5.3.4

Well, I know our webserver is kinda old, but it will be replaced in near future.
The problem is that there are other applications running I'm not the owner of, thats means it's not as easy to update.