Monday, April 16, 2007
IIS 6.0 and other hidden options
I had thought that I had found the internet nirvana.
And it was in the form of:
ASPExecuteinMTA
This little gem reports to have all sorts of benefits for turning on. Statements like:
Your system will run significantly faster, and amazing technical descriptions like that.
However, what they don't tell you is when you run in this mode, you also loose the ability to login as credentialled users. You can still login, mind you, but any scripting you use will default to IIS's IWAM_USR account - which generally is given limited to no permissions other than reading the directory of the website you are hosting.
This is a good thing - because if you give the IWAM_USR account permissions to, um, let's say, write, or perhaps Full control -all sorts of security bad things can happen.
Like for instance being swarmed over by lovely, furry, fuzzy script kiddies and the like.
However, when you turn on the MTA switch, you will find that the FSO (or file scripting object) no longer functions because even if you login as "administrator" on the page that previously worked, it will now cause FSO to have security permissions of, IWAM_USR. And all sorts of things will happen.
Like for instance - "Directory does not exist" or "File not Found" - even when obviously the directories do exist, and the files are there.
I love microsoft....
And it was in the form of:
ASPExecuteinMTA
This little gem reports to have all sorts of benefits for turning on. Statements like:
Your system will run significantly faster, and amazing technical descriptions like that.
However, what they don't tell you is when you run in this mode, you also loose the ability to login as credentialled users. You can still login, mind you, but any scripting you use will default to IIS's IWAM_USR account - which generally is given limited to no permissions other than reading the directory of the website you are hosting.
This is a good thing - because if you give the IWAM_USR account permissions to, um, let's say, write, or perhaps Full control -all sorts of security bad things can happen.
Like for instance being swarmed over by lovely, furry, fuzzy script kiddies and the like.
However, when you turn on the MTA switch, you will find that the FSO (or file scripting object) no longer functions because even if you login as "administrator" on the page that previously worked, it will now cause FSO to have security permissions of, IWAM_USR. And all sorts of things will happen.
Like for instance - "Directory does not exist" or "File not Found" - even when obviously the directories do exist, and the files are there.
I love microsoft....
Friday, April 06, 2007
Speaking of SQL
I have run into a situation where I am not sure if my SQL server is operating normally, or if it's madly running out of control and into oblivion (which is a great, fun game btw).
I manage and design a website www.toolup.com.
On this site, I use SQL extensively. And the ASP pages that I write use connections and recordsets quite a bit. When I go to look at all the processes running on the server I find hundreds of sleeping connections. Is this a result of connection pooling by the system. Is it a result of connection pooling by the IIS web gardens, of which I have probably 64+64 + 32 for a total of 160 actual web processes running the website.
The website seems to respond very quickly. On the order of 1/2 second or so. Often times returning in a 1/10th of a second. So performance is not an issue.
I have run through the code and made sure that I have closed my connections.
However, doesn't the connection get automatically closed upon the closure of a script? Is running conn.close() redundant?
does conn.close() happen when you execute
set conn = nothing?
So while I contemplate this fine feature of SQL - I find that I am staring at roughly 647 pids, most of which are happily sleeping, and my server's CPU load is fairly low all of the time, with occasional spikes to the disk or CPU load.
I just can't help but think that all of these pids should be going away after they complete.
I manage and design a website www.toolup.com.
On this site, I use SQL extensively. And the ASP pages that I write use connections and recordsets quite a bit. When I go to look at all the processes running on the server I find hundreds of sleeping connections. Is this a result of connection pooling by the system. Is it a result of connection pooling by the IIS web gardens, of which I have probably 64+64 + 32 for a total of 160 actual web processes running the website.
The website seems to respond very quickly. On the order of 1/2 second or so. Often times returning in a 1/10th of a second. So performance is not an issue.
I have run through the code and made sure that I have closed my connections.
However, doesn't the connection get automatically closed upon the closure of a script? Is running conn.close() redundant?
does conn.close() happen when you execute
set conn = nothing?
So while I contemplate this fine feature of SQL - I find that I am staring at roughly 647 pids, most of which are happily sleeping, and my server's CPU load is fairly low all of the time, with occasional spikes to the disk or CPU load.
I just can't help but think that all of these pids should be going away after they complete.
