[Solved] Extremely Slow Queue Changes (30 sec +)

[connellgosling]

Edit: Issue solved by turning off agent move notifications - client end was waiting for all emails to be sent prior to loading.

Hi all,

First post here, so forgive me if I omit information usually included. I'll start by using this as a basis:

I am using OTRS Version: 3.3.9
I am using OS: CentOS 6.5
I am using Database: MySQL 5.5.4

I have this problem: When moving a ticket from any queue into any other queue, it takes 30 seconds or more to process.
I am encountering my issue on this screen: Any article on any ticket.

I can replicate the issue by: Opening any ticket in any queue and using the queue dropdown to select another queue to move it to. The issue can be replicated in any browser on any host, with tests including Chrome, Firefox, IE, Safari and Opera on Windows and Mac hosts with a mix of OS versions. The issue occurs for all agents.

This is what I've tried: Assuming it was a performance issue, I have tried following the OTRS chapter for improving performance. I have also tried tweaking apache and MySQL and ensuring that these are running optimally. Using the OTRS Support Assessment tool under System Administration in Admin shows all green - everything configured optimally. SQL benchmarks also return everything running very quickly. I can provide further detail/screenshots etc. on things I've tried if it may assist. System logs do not report anything wrong when tickets move between queues.

These are the posts I've found that are relevant, but don't seem to answer my question: I've scanned around and read a lot of general 'OTRS is running slow' threads, this seems to be a popular issue in OTRS, but nothing has addressed moving between queues as a specific issue. With the exception of moving between queues, the entire system performance feels fast and acceptable - the only speed issue is the queues.

I've looked at the HowTos on this: I have not seen any that apply.

I've looked at the Docs. Specifically I've gone through the relevant version of the OTRS doc on performance and followed all advice and steps there.

The logs say: Nothing out of the ordinary. Moving between queues does not trigger any events (unless they're at a log level other than default?)

I've done a non-specific generic search for the error message and it says: N/A
That doesn't apply to me because: N/A

My question is: What factors influence the speed at which a ticket changes from one queue to another? What things can I try that will improve the speed of queue change, or what things can I check that may be impeding this one specific feature from performing well?

Thank you in advance for any advice you can give me! Please let me know if there are other details I can provide.

Cheers,
Connell

[EXG133]

Do you have custom events or notifications that trigger on queue move? Can you try creating a new testqueue where only you have access and see if moving is as slow?

[connellgosling]

Hi EXG133,

When a queue move occurs, an email notification is sent to agents who are subscribed to the destination queue that a ticket has been moved into it.

I have created a test queue that only I have access to. I tried moving a ticket into this queue and the move operation took no more than two seconds.

We are definitely onto something here. Do you have any ideas what this means - could the delay be caused by the system waiting for move notifications to be sent out?

[connellgosling]

Hi EXG133,

Through my own testing and watching the system log during a queue move, I can see the emails sending to agents with the move notification switched on processing and the moment this finishes, the queue move operation suddenly completes. It surprises me that this is not an asynchronous operation - I had thought it would schedule notifications to be sent while allowing the client end to load immediately.

I have turned off the move notification event for all agents and now queue changes are very fast. This has solved my issue.

Thank you very much for your reply - your prompts have led me to discover the solution.

Cheers,
Connell

[EXG133]

All mails are handled synch. It's quite strange that sending mails/notifications takes 30+ seconds. I suspect you're also experiencing slower than usual performance on other actions. I would suggest verifying mod_perl is properly used by apache and that your mail server is responding normally.

The ideal solution of course is configuring a local MTA. As an example of the impact: we went from ~1.7s page loads to ~0.9s for mail related pages when we switched to a local MTA.

[schulmann]

I'd check dns resolving.