Submitting a ticket is very slow

[as_barrus@…]

Hello Trac developers,

I use trac for my small development team. The wiki is responsive, as is looking up tickets and searching, etc. Browsing the subversion source is fast. But sumbitting any ticket is very slow. Creating a new ticket takes about 30 seconds to respond after I press the "submit ticket" button. Likewise, when updating a ticket, it takes about 30 seconds for trac to answer that the update was successful. I'm running trac 0.9.5. The trac server is a dual 2.0 Ghz machine with a four-member SCSI RAID-5 stripe. The load average is 0.01. Trac runs against an Sqlite database. I admit I don't know much about how that part works, but I suspect it could be where the problem lies.

It's getting bad enough that I'm considering reinstalling on a new server just to see if the problem goes away magically; or point it to a mysql or postgress db - just for troubleshooting. But solving it the correct way would be a lot nicer for me!

Attached is a screenshot from the Tamper FF plugin to show the load times for various pages. I am happy to provide any additional follow up data to help me solve this problem. If this is the wrong way to request trac help, then please redirect me. Thank you! Trac is great and I want to continue using it!

[as_barrus@…]

Tamper FF plugin showing load times from trac server

[athomas]

This is almost certainly related to notification. When Trac attempts delivery of notification mails it will block until the mail server has taken delivery, so things like spam filtering, RBL lookups, DNS timeouts, etc. will all slow down notification and consequently, the web interface.

[cboos]

Yes, but I don't see why this make the ticket invalid. If those delays are somewhat inevitable, I see no reason why they should interfere with the ticket creation/change, as it's only a notification, not something that could invalidate the submission.

Why not address the problem by making the notification asynchronous?

[athomas]

Frankly, my view is that if you're seeing a delay of 30 seconds from an MTA, then it's misconfigured.

All mail servers that I'm aware of can be configured to skip these checks if accessed from the Trac server's IP address, so adding the complexity to Trac seems unnecessary. Still, if you think it's necessary...

[athomas]

Another thing to consider, if you go ahead, is warding against fork bombs caused by rapid ticket creation/updates. MTA's generally already have this facility built in of course, but you'd have to replicate that logic in Trac.

[cboos]

Frankly, my view is that if you're seeing a delay of 30 seconds from an MTA, then it's misconfigured.

I agree, and I'm aware that one problem with my proposal is that it could make the detection of such a misconfiguration a bit harder.

On the implementation p.o.v, I was thinking of queueing a notification "event" and have a dedicated notifier thread, which would simply do the notification of those events, sequentially.

If that thread detects abusive delays, it could log a warning or even an error.

[eblot]

Why not address the problem by making the notification asynchronous?

I would say "keep it simple". Or "keep keeping it simple" ;-)

Introducing background tasks in Trac seems to be quite overkill, and would probably lead to create a new bunch of hard-to-solve issues, to fix up the issue at the wrong place (in Trac, rather than at the MTA level).

I don't see the point to introduce serialization in email notifications, whereas the MTAs are already able to receive concurrent notifications.

Trac is not a MTA debugging agent. To detect long latency issues, it's far easier (and safer...) to retrieve the time before the SMTP connection and after the notification, and log a warning message when the time difference reaches an upper limit.

[cmlenz]

I strongly agree with Manu. Let's close this again.

[ghazel@…]

We have run in to slow ticket posting as well, and have found it very difficult to debug. This appears to us as a problem with Trac.

Please, at least log about slow notification submissions.

I would rather the ticket be created and mail be delivered later or not at all. Blocking the browser creates opportunities for the ticket to be lost, including the user cancelling out of frustration. Imagine if sending an email waited until it was submitted to the MTA.

[jonas]

I'm closing this as fixed now (r7322, r7323). Notification mails are still sent synchronously but slow MTAs are now detected and logged making troubleshooting easier.