There is a VERY bad problem with Active Server Pages (ASP...or what is sometimes known as "classic ASP") which prevents it from being a viable system on which to build a "big IT" project. For 2 years we've been fighting a problem in which the IIS (Internet Information Server) 6.0 web servers will run fine for a while. But then after 18-20 hours, every pages will stop running properly and instead display random errors (that change from refresh of the page to refresh). The errors always say things like "Cannot find property or method" regarding classes that do exist, or "Cannot create object". The exact propery or object changes from "refresh" to "resfresh"...even on the same page. Restarting will fix the problem for an hour or so...but then it reoccurs. Only a hard reboot will fix it for another 18-20 hours. And then the cycle repeats itself.
We started a ticket over 2 years on this. Today Microsoft acknowledged the problem publicly with a KB article: http://support.microsoft.com/?scid=kb;en-us;914156
Basically the problem is that ASP fragments the heap under certain conditions:
1) When an app uses INCLUDE files
2) When an app uses significant memory
And it doesn't defragment the memory and as a result, will ALWAYS crash IIS in this way. The new restart services of IIS 6.0 don't help, becuase only a hard reboot can truly get rid of the defragmentation.
Of course, two things that any site that has any sophistication has lots of INCLUDE files and any site that has any traffic uses lots of memory. If both of these apply to you, your ASP site is in trouble. This is what's called a "bug" in my book. I'm sure if ASP were MSFT's current technology they would have to fix this. But Microsoft has moved on to ASP.NET...so I suspect the incentive is pretty much nil.
If you look at the KB article, Microsoft gives a "workaround" (which is the same workaround that they suggested to us). The workaround is to rewrite your INCLUDE files as COM objects. The article sites a # of benefits like speed, etc..
The KB was probably written by a systems engineer who knows alot about running systems, but has no idea how computer software is developed, and how impractical this workaround is in the real world. In a previous position we went down the COM object route. We did it for other reasons...becuase it was the Microsoft "best practice" at the time. It's obvious why it no longer is. The problems we ran into were:
1) Memory: COM objects have a known memory leak problem. If two COM objects reference each other and you set them to Nothing, they don't clear themselves in memory as they should. The problem is due to the internal way that COM objects work and was fixed in .NET with a rearchitecture. But that isn't an option for you if you use COM objects. This COM memory leak bug will cause your machine to eventually crash, EVERY TIME.
2) Slowness to initialize objects: COM objects are not designed to be created and destroyed thousands of times like .NET objects. Our object rich COM model running on the internet was VERY slow...some pages took 5-10 seconds to render. One way to work around this is to not use objects in COM, but instead use functions. But of course, this "solution" causes almost as many problems. A non-object oriented framework is exponentially more difficult to debug and maintain which makes delivering the code on time and on budget frustratingly (and unnecessarily) difficult.
3) Slowness to develop: This was a real show stopper. Every time a change is made in the COM object code (the COM object has to be completely recompiled from scratch, which took 2-3 minutes on a state of the art machines (This # could vary depending on the size of your COM objects). Also, many times IIS would lock the COM object .dll, so in addition, IIS had to be stopped and restarted too, which took another minute or two. (The latter might be alleviated with object pooling, but all the other negatives forced us to abandon COM before even looking at this possibility).
How does this affect things? When code is created, it is never right the first time. Even creating a single function is an iterative process where it's coded, run, bugs are removed, and the process repeated. A typically complex function created by a top notch developer might require 3-4 iterations...and an average developer might require 10,15 or more. Being able to iterate quickly is what allows you to deliver it on time and on budget. If creating just a single function requires 9 more minutes for your "star" developer and 30 more minutes for your average developers, you are going to have problems. It is FRUSTRATINGLY difficult to develop under these circumstances and try to meet time and budget commitments.
I tried to explain to the Microsoft systems engineer why this was impractical, but simply got the standard "spiel" repeated to me that COM objects were wonderful and the way to go. Obviously he believed something he read from a KB article, more than me, who he did not realize had personal experience with this supposed "solution".
Conclusion: If you develop a web app with any sophisticiation or any size, ASP (classic ASP) is NOT a suitable or scalable environment for you. Instead go to a non Microsoft platform. If you choose to say with Microsoft, choose the newer ASP.NET.
Ian Ippolito
Deep link provided by Citebite