Reputation: 435
I've inherited a very old classic ASP script, that's used to send emails to around 5,000 to 10,000 recipients as a time, bcc'ing in batches of several hundred. This sits on a dedicated server with a high traffic website.
The server.scripttimeout property for the mailing script is set to 10 mins, and the entire mailing list is loaded in memory to a scripting.dictionary, which is used to perform email validation and duplicate removal.
This script can potentially be used by 10 to 20 people concurrently, each sending up to 10 mailshots each.
I feel that this cannot be good for the server, having the potential for so many long running processes to happen at once, however cannot cite technical reasons why. Can this cause issues with threads being blocked, or memory consumption? Could this potentially disrupt service to the website?
Can anyone give any technical reasons why this is not a good idea? I feel this script should be replaced with a mail server, however, I need technical reasons to cite first.
Any input in appreciated.
Best, Jack
Specifically, I'm thinking that each time this script is ran, a thread from the ASP threadpool will be busy doing the mailing.
According to http://www.iis.net/ConfigReference/system.webServer/asp/limits , the processorThreadMax property:
"The processorThreadMax attribute specifies the maximum number of worker threads per processor that IIS may create.
Note: This setting can dramatically influence the scalability of your Web applications and the performance of your server in general. Because this attribute defines the maximum number of ASP requests that can execute simultaneously, this setting should remain at the default value unless your ASP applications are making extended calls to external components."
Assuming a single processor server, with this value configured at the default (25 threads) Would I be right in saying that if 20 concurrent users all performed mailshots at the same time, only 5 threads would be available to serve the website?
If I am correct, then I think this reason alone is enough to show this method is not sustainable and should be replaced with something more durable.
Can anyone confirm if I am correct?
Upvotes: 3
Views: 839
Reputation: 9912
A couple of reasons to consider:
What if you'll reboot the IIS service / app pool during the web site maintenance?
What if your mailer will consume an enormous amount of resources?
What if some other page will consume an enormous amount of resources (preventing your mailer to work correctly)?
PS: And how do you now run your script? If you're doing it by going to a specific page in browser, you should also consider maintenance reasons: browser is likely to cancel the request by timeout, and, although you can work-around various problems that arise (IIS cancelling the script execution, inconvenient logging), it still adds to the heap of disadvantages.
Upvotes: 1