Minimizing Time to Send Email
Programmers using Chilkat to send email can do some simple things, and can avoid common mistakes to optimize the time it takes to send an email.
1) A common mistake is when a programmer calls mailman.VerifySmtpConnection and mailman.VerifySmtpLogin prior to actually sending the email. The intent of the Verify methods is for an application to examine connectivity and login success after a call to SendEmail returns a non-success status. The best option is to simply call SendEmail first. If successful, then all is good. If not, then first examine the mailman.SmtpFailReason property. It will provide a general reason for failure, and two of these reasons are ConnectFailed and AuthFailure.
Many mail servers are SLOW in the time it takes to respond to a login. For example, we’ve seen many cases where Office365 takes 3-4 seconds to respond to the AUTH command (i.e. the login). An application wouldn’t want to experience this delay twice for every email sent. This is what happens if VerifySmtpLogin is called prior to each call to SendEmail.
2) When SendEmail completes successfully, Chilkat leaves the authenticated connection with the SMTP server open so that a subsequent call to SendEmail will use the already-established connection. However, if the connection is idle for a long time, a mail server is likely to close the connection. This is no problem for Chilkat because if SendEmail finds the connection closed, it will automatically re-establish and re-authenticate and all is good — except for the time delay in performing the re-connect and re-authenticate, which can be large. Therefore, an application could periodically call mailman.SmtpNoop to prevent the connection from being idle for too long, and thus prevent the mail server from closing the connection. This way, it’s more likely that the next SendEmail will find a valid/authenticated connection.
3) The LastErrorText property is common to most Chilkat objects. A feature of the LastErrorText is that if VerboseLogging is turned on, then the elapsed time (in milliseconds) for each context is shown within LastErrorText. (For cases where a context takes less that 1 milliseconds, the elapsed time is omitted.) Thus an examination of the verbose mailman.LastErrorText can help identify where the time was spent in sending an email. One can identify the time spent in the TLS handshake, in the SMTP authentication, and in the sending of the DATA and waiting for the final SMTP status response.
4) Finally, if you’re using an old version of Chilkat (meaning years old), make sure to update to the latest version. Over the years Chilkat is always improving the internals for performance and memory usage. At this point in time, slowness in sending email is highly likely to be caused by server slowness or other external factors, and not something within Chilkat. (I would venture to say this is also the case for any client-side implementation of SMTP — the slowness is not likely to be caused by the client-side implementation.)