*web/email is very slow

[Mike Hatfield]

We have a relatively fast internet connection (80Mbit down and 28Mbit up), however it takes about 6 seconds for *web/email to generate and send the email.
This doesn't sound much until you are waiting at the screen for the process to complete.
I was thinking of setting the mail server argument to null and saving the generated email in the outlook/new folder and writing a background process to send the email.
If I do this, how do you then send the generated .eml file?

Thanks

[Allen Miglore]

How about a background process to run *web/email?

[Mike Hatfield]

Hi Allen,

I had though of that but I thought there might be a 'quicker' solution.

[koenv]

Does your email have attachments and what PxPlus version are you using? The way attachments got converted to base64 was pretty slow pre version 13.

[Mike Hatfield]

PxPlus 14.10
Email is HTML with base64 encoded attachment.
The base64 encoding itself doesn't take long.
It's the actual *web/email program that is slow sending the email.

[Mike King]

While it might be *web/email, this program has been out for years and this is the first report of anybody encountering slowness.

Perhaps its related to the email/smtp server you are connecting to?

Often web sites do what is called 'Tarpitting' which is they intentionally slow down email submission to help reduce spam.  If a mail server ran at full speed a spammer could send hundred of thousands of emails a minute, whereas if each email waits 1-2 second before acceptance then the most you send is 30-60 per minute with minimal impact to the end-users,

Another thing that may slow up email is if the email server is checking the in/outbound addresses.  I know our mail server does -- that is both sender and receiver email addresses are pre-validated to see if the server can determine if they exist.  It also does a spam check both on the inbound server (to see if its blacklisted) and runs the email contents through a spam/anti-virus filter.  These checks all take time -- more for larger emails.

[Mike Hatfield]

I put a TRM() round the call email form program in our invoice print program.
It averages 5-6 seconds from calling the email format program which in turn calls *web/email until it returns to the invoice rpint program.
We use smtp2go for a lot of email both for ourselves and end users.
Their servers are quite fast. Perhaps as you say it is the sender/recipient verification that is taking the time.
I can send you the email formatting send program and attachments if you think it would cast some light.
This also might help diagnose why *web/email is not receiving the sent status so it can remove the .eml file from the outlook/new folder.

[Mike King]

What I might suggest is try passing an smtp server an invalid userid/password and time how long it takes for the error to be returned. This will allow you to get a feel as to if the system is taking a long time generate your email for sending or if the smtp server is taking a long to process it.

Generally a bad userid/password should disconnect quickly so if this time is fast but with a valid userid/password it likely the mail server itself is slow.

Also if you have a different mail server (perhaps a gmail account or your own in-house server) I would try that as a test to see if that is faster so you determine where the issue may be.