2
votes

I have just moved a customer's Classic ASP website to their own VPS server (Windows 2003, 32-bit, IIS6, Virtual SMTP server) and after about 12 hours the website starting failing whenever it tried to send emails (CDO.Message).

Any script that sent an email took a very long time before it returned the error: Active Server Pages, ASP 0113, Script timed out. The standard timeout is in place. Strangely the custom error page which sends errors to me using the same email send method and settings (same function actually) was able to send me the error notification.

I needed to get the website going so I stopped/started the SMTP server which didn't help, then restarted IIS which resolved the issue immediately.

I am worried this might happen again. Any suggestions for what can cause this problem or does the default SMTP server need some additional settings to cope with a reasonably high-volume website?

2

2 Answers

2
votes

Since classic ASP code has to call an external COM based component in order to send email (that's what you are doing if you are creating a CDO message --- anytime you have a CreateObject call in your asp code, that is COM), the asp code will appear to hang if the external component takes a long time to respond. For example, most SMTP components will synchronously try to send the message to the SMTP server blocking your asp code from executing until the email message is sent. This becomes a problem on very busy SMTP servers, as they can be very slow to respond to connection requests and to SMTP commands. Another bad situation is that many ISP's/hosts attempt to throttle the speed you can send email by purposefully making their SMTP servers respond slowly. Even worse, some hosts will go so far as to actually make subsequent connections over a set time period progressively slower. This can significantly impact your site performance since you are typically having your page code blocked during the SMTP send.

The best solution would be to use a host or SMTP server that does not enforce such restrictive measures. Barring that, there is a way to work around this by using message queuing. If you are using CDO, this means you have to configure the Microsoft SMTP Service on your IIS web server for use. This can be configured properly even if you do have other SMTP software on the IIS machine. Once the Microsoft SMTP Service is running on your IIS server, it will be able to queue email on the server and forward them to the configured SMTP server asynchronously to your application / page code. When configuring the Microsoft SMTP Service, you must define what it calls a "smart host". This is simply the SMTP server you are going to route the outbound email to for delivery on your network.

Once you have that configured, you just have to change your code that uses CDO to queue the email message instead of trying to send it. In your CDO code, you should have a line that sets CDO field values which look something like this:

objFlds.Item("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2 

You want to change the value for the "sendusing" field from a value of 2 to a value of 1. These are the enumerated values for the cdoSendUsingPort (2) and cdoSendUsingPickup (1) enums. Once you do this, you can also drop the "smtpserver" and "smtpserverport" fields as these are overridden by however your Microsoft SMTP Service is configured. Once you do this, your asp code will quickly generate the email message and it will be queued in the IIS server's mail pickup folder. So your application / page code will run much faster. The outgoing emails will potentially accumulate in the queue folder as the SMTP Service slowly works on delivering them in the background. It doesn't make the email get send any faster, but it does prevent your code from blocking due to a slow SMTP server.

0
votes

I later found that the actual sending of the email was not causing the problem but the fact that I was generating the HTML body for the email by retrieving HTML from another ASP page (via the XML object).

I tried various things to fix the problem including switching mail components (to Jmail) and using different versions of the XML object but the problem would still occur intermittently.

In the end I changed the code to generate the HTML for the email body instead of calling another ASP page and reading it's response.

Eliminating use of the XML object seems to have resolved the problem but the cause was never found.