Long delay after submitting a post.

[Jake Bunce]

Problem: My users and I have been experiencing a long delay after hitting the "Submit New Thread / New Reply" button. It will hang for about one minute and then procede to the confirmation screen. This is an intermitant problem that isn't really isolated to any particular time of day or anything. The rest of my site is fine, including regular forum browsing. I contacted my web server about this. They said given the circumstances the problem might be unoptimized posting code.

Related Questions: What kind of server overhead does the code for posting new threads and replies have?

[bigbigsavings]

Jakeman,

We were having the same problem, and it had to do with EMAIL NOTIFICATION. Try turning it off, and i'm sure the problem will go away.

Our users were also getting up to 30 emails every single time an email notification would go to them.

I tried getting help from some people here, but to no avail.

Alex

[Jake Bunce]

is there any way to turn off e-mail notification without turning off all the other e-mail features?

[Wayne Luke]

Originally posted by bigbigsavings
I tried getting help from some people here, but to no avail.

This is the first I have heard of this sort of problem.


Jakeman, if your email server is overloaded it could cause a problem. However that might not be the case because it should queue the messages sent to it relatively fast. I have only had a problem if I tried to send 200 or 300 emails at a time. This is a limitation of the mail function in PHP not vB. It simply was not made for high bandwidth use.

Posting messages is the most resource intensive function of vBulletin. When you post a new message it must:

1. Censor the text in the message if necessary.
2. Convert all HTML entities to their proper notation if necessary.
3. Index each and every unique word in the post. (word and searchindex tables)
4. Send all email notifications out. (subscribedthread table)
5. Send all Moderator mail notifications out. (moderator table)
6. Update the thread information. (thread table)
7. Update the forum information. (forum table)
8. Update the user information. (user table)
9. Actually save the thread. (post table)


For a long post on a busy server, it may take a while to perform these steps, especially since only one user can write to anyone of these tables at a time.

[bigbigsavings]

wluke,

We have 2 load balanced web servers and one database backend. With email notification turned on, it takes up to a minute and sometimes more for a post to "go through." With it off, it takes under a second.

As for turning off email notification without affecting OTHER email features, I WISH there were an option to do this as we have not been able to solve our email notification problem yet.

Alex

[Jake Bunce]

I guess the most effective way is to remove the "E-mail Confirmation" check box from the posting templates?

[blade]

Same problem at my forums too except it's a wait getting to the part you can type your post. Only started after the upgrade to version 2. Takes 10-15 seconds to start typing a reply or post. Sometimes longer.

I disabled email notification under "change options" but it didn't help the speed much. Then I removed the option from the "new reply" template and I could barely tell a difference either.

[tubedogg]

Turning off email notification wouldn't have any effect *before* the fact.

[blade]

But it's still the delay when hitting the "new topic" button. Takes 10-15 seconds just to get to the field where you can type. I removed it in templates for that also.

[tubedogg]

They are saying the delay happens when they *submit* the thread, not when clicking the button to go to the message entry screen.

[Jake Bunce]

but blade is having the other prob i guess.

one thing i noticed during the beta progression was that once the javascript code was added to the new posting templates for the clickable smilies and text styles it slowed down loading of those pages for me. I ended up taking out the text styles stuff and modifying the clickable smilies feature and it made it go faster.

[tubedogg]

Javascript does slow the client down, from a little to a lot depending on the client and the amount.

Netscape is really slow at it, IE seems to be relatively fast.

[roy7]

For a long post on a busy server, it may take a while to perform these steps, especially since only one user can write to anyone of these tables at a time.

And thus enters BDB and InnoDB tables, which can have multiple writes at the same time.

As for the delays with posting, turning on email notifcation doesn't send you an email right when you post so it should have no effect, right? Of course, it might need to mail all the other people... right okay, I see.

What you can do is change the mail server php is using. If you are using a remote SMTP server from your ISP or something, try setting up sendmail/qmail/postfix/whatever locally so you can deliver mail from your web server box. Then have PHP use that for sending emails. This way, it'll connect to the localhost, hand off the email to the mails erver software, and move on with life. It should be very fast, since PHP doesn't wait for the email to go out or anything, it just gets queued.

If you already use a local mail server then I don't know what to tell you... php doesn't try to connect to each remote mail server itself to deliver emails, right? It'll connect to an SMTP server to dump all of them off?

-Jonathan

[roy7]

Speaking of which, if you use qmail you can do this (from a comment on the php Mail docs page)

[email protected]
26-Feb-1999 06:17
To integrate qmail in mini-qmail config I set sendmail_path
in php3.ini to /var/qmail/bin/qmail-inject

By default if you don't override it, php uses

/usr/sbin/sendmail -t -i

to send email. This will, in fact, look up the remote domain's MX record and connect to deliver the email directly, while you wait. I'm looking into how to get sendmail to queue it instead. This is what is causing your delays I'm almost certain. Some of those servers might be down or slow, and sendmail sits and waits for it to finish.

Will let you know as I learn more. (We'll be using postfix on our box which should let us queue the emails easily instead of immediately trying to send them and waiting for it.)

-Jonathan

[roy7]

Jakeman,

Try this:

grep Delivery /etc/sendmail.cf
grep Delivery /etc/mail/sendmail.cf

and see if you see a line "DeliveryMode=something". If so, what is something? If it's background or queue, well, I'm not sure what's going wrong though. If it's immediate, that's a problem.

Try setting the sendmail options in php.ini to:

-ODeliveryMode=background -t -i

which should force it to use background delivery. This means sendmail will go ahead and try to send it right away but you won't need to wait for it, vs immediate mode which trys sending it right away and calling sendmail will wait until it has finished. If DeliveryMode in sendmail.cf is already set to background or queue though, this shouldn't have any effect and the problem must be elsewhere.

-Jonathan