Odd, extended lag on form submit (and finalize)

[mikkolindberg]

I'm coming across an odd issue, that I've googled thoroughly, and searched on these forums as well, to no avail. Seems maybe a bit unique?

We've been using FormTools for about seven years or so. I don't recall if this was an issue in the beginning, but now, the finalization of a form submission has a VERY noticeable lag. As in, 15-30 seconds long.

Specifically, when a user hits the final submit button on our form (or I run a test), the page begins to process, and one can see the spinning circle on the browser tab. This goes on for an extended period, to the point where people are obviously hitting the submit button multiple times in frustration. Eventually, the submission goes through.

I have narrowed down the cause to the automated emails. If I turn them off, the form submission takes only a second. The emails cause the lag whether I have SwiftMailer turned off or on. Is there something dated with the API? Is there a way to speed this up without writing custom code? Crossing my fingers that someone has resolved this already...

Thanks,

Mikko

[alexh]

Hello! I had the same issue and narrowed it down to the email as well. It turned out some settings were turned on in a new version of cPanel (WHM) for spam prevention. I can't remember the exact setting, but I think it was waiting for a response from the receiving server or something. I can look it up when I get back to my computer later today if needed.

I was able to modify the settings in cPanel and it helped. I first notified it when I started getting duplicate submissions - people were impatient and pressing it a bunch of times.

[mikkolindberg]

Yeah... That could be it. We are on a shared server using cPanel. I poked around the settings and didn't come across anything that looked like a potential cause. The cPanel was upgraded earlier this year, I believe. Someone hit the submit button seven times today!

If you could track down what you did, would much appreciate it!

[alexh]

Do you have access to WHM or just cPanel? Are you using one of he larger hosting providers?

[alexh]

Found the post from cPanel support that helped me:

- Introduce a delay into the SMTP transaction for unknown hosts and messages detected as spam.

The SMTP receiver will wait a few additional seconds for a connection when it detects spam messages in order to reduce inbound spam. The system excludes the following remote hosts from the delay: Neighbor IP addresses in the same netblock, Loopback addresses, Trusted Mail Hosts, Relay Hosts, Backup MX Hosts, Skip SMTP Checks Host, Sender Verify Bypass Hosts, and Greylist Trusted Hosts.

This can be disabled from Home »Service Configuration »Exim Configuration Manager in the basic editor.

https://forums.cpanel.net/threads/smtp-v...ow.498961/

[mikkolindberg]

Thanks, we are indeed using a large hosting provider.

And, so... I called to inquire about changing those settings, and basically was told we had no access and that changing those settings on a shared server was not an option.

Essentially, any email sent through PHP is going to have a major delay due to authentication.

But it got me thinking... Form Tools does have the Swift Mailer module which, in theory, is supposed to "override the default mail() functionality" and use SMTP instead, right?

So I've been bashing my head at various configurations for hours. I went into our site cPanel and created some new email accounts. I've been trying variations of logins with Swift Mailer, and I can get a fast email to go through when testing within the module.

But... when I go to test the responsiveness of the automated emails within an actual Form Tools form, the lag returns. And form submissions themselves continue to go through painfully slow.

I did find an email authentication page in cPanel that I do have access to, and have been messing with the settings for:

DKIM ("DKIM is a means of verifying incoming email. It ensures that incoming messages are unmodified and are from the sender from whom they claim to be. This feature works to prevent incoming spam messages.") and SPF ("The SPF system allows you to specify servers and IP addresses that are authorized to send mail from your domain(s). This feature works to prevent outgoing spam messages.")

Not sure if it will help anything. According to the help page, "as these are DNS settings, they may take up to 24 hours or more before they begin to take effect."

Thinking I may step away for a day or two.

Side note, I don't suppose the Swift Mailer upgrade discussion on this same forum might be an option?

[mikkolindberg]

One last thought and I will stop obsessing, for today. Might it be possible to use the Hooks Manager module to send the email after the "thank you" page loads? A lag at that point wouldn't be a problem. Or maybe move a thing or two in the API that would make the automated email script run at a later point?

[mikkolindberg]

Thought I would post a work-around I came up with for this problem, in case anyone else is on a shared web hosting server. Indeed, it was quite likely the SMTP delay setting causing the issue, or SpamAssassin, which both seem to have come about in a somewhat recent cPanel upgrade.

Fix I came up with was to create new email addresses on our domain, and have all submissions forwarded through them. So, for emails that we need to receive, they go to example@hosteddomain.com, which then is forwarded to example@ouremailserver.com.

Emails that need to go to the email address entered by a user into the php form are piped through another email forwarder. So they go to secondexample@hosteddomain.com, which then forwards the email to a php mail script, which parses the email into sections, grabs the needed portions, and then forwards the necessary portions to the appropriate email address.

Lag on submit has gone down from about 13-15 seconds to maybe 1 or 2.

Cheers.

[alexh]

Yikes that's a complicated workaround! Thanks for the info! Hopefully there will be a fix for it. Maybe putting the emails into a batch to send out on a regular schedule - but not requiring the script to wait until it's sent.