Just FYI should anyone else come across the problem, it was resolved by disabling S/MIME support. Peter Fern wrote:
Bartsch, Martin msg asp gmbh wrote:
Disable CheckMX Record Sysconfig Framework -> Core CheckMXRecord: No
-----Original Message----- From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Peter Fern Sent: Tuesday, October 24, 2006 8:47 AM To: User questions and discussions about OTRS.org Subject: Re: [otrs] Slow email response submission
And apologies for replying to my own topic, but I forgot the essentials:
OTRS v2.1.2 Apache 2.0.58 Perl 5.8.8 mod_perl 2.0.2
Hi Martin, Thanks for your reply, and apologies for the belated reply on my part - I've been flat out on a number of projects recently and haven't had time to revisit this issue, however management are frothing to get this in and functioning.
Unfortunately, this change has had no affect - I'm still seeing delays of up to 300secs when processing mail responses, and the debugging output for this module is rather light, so that hasn't given me any insight. I didn't really expect a great improvement be making this change (unless there were known bugs with the resolver code), since these test messages would only have required lookups against internally hosted domains, and I get MX lookups back in milliseconds using various tools.
I must say - this is quite perplexing, and unfortunately it appears that the CLI perl scripts don't output performance data either, so I can't see if these same delays are apparent when automatic responses are generated, or just from the frontend. I also have other packages on the webserver that deliver mail very promptly so it has to be OTRS (or a dependancy?) specific.
Also, DNS and MX are both attached at 100mbit (virtually, they actually all exist on a single machine under Xen) so there are no network latency issues. Anyone have any other ideas - since I just can't deploy with this performance?
Regards,