I have a legacy Classic ASP web application that performs slowly on my current Windows 10 / SQL Server 2017 Dev machine as well as a Windows server 2016 machine.
In more detail, the ASP parts of the application construct and execute a lot of queries on the SQL server behind it. The queries seem to be taking about 5-10 seconds each to execute and some parts have more than 200 queries resulting in script timeout errors.
The interesting thing is that the same code ran on another Windows 10 Dev machine and performed just fine (the main difference is Windows defender being turned off on that machine), as well as on Windows server 2008.
I've tried disabling real time protection as well as Windows defender altogetger on my Dev machine with no luck.
Any ideas or hint as to what could be causing this?
Turns out the very undocumented (local) value for the database source was what was causing the delays. Changing (local) to the actual machine's name in your Classic ASP project's configuration will fix the issue. This is usually found in a some ASP configuration file within your project (e.g. config.asp).
I will edit this answer with several other topics that I found throughout my research which should apply to anyone having issues with Classic ASP projects.
What's also interesting and hasn't been answered yet is that two machines with (basically) the same stack were having different results.
Related
I've got the undoubted joy of having to put a very simple 'classic ASP' internal website on to a Windows 2000 server (which I believe will be running IIS 5).
I won't have access to this server until the weekend, and all of the original development & testing of this website was all done on IIS 6/Windows 2003.
The website is incredibly simple (some ADO database access to SQL Server, basic vbscript and bits of javascript, HTML forms, simple CSS). It's only going to have a shelf-life of a few months (I know we've all heard that one before!) and then both server and software will be upgraded (replaced, in actual fact). It's completely internal to a small local network, there are no external connections to the network, no session or state information being held, no specific user (or SQL Server) accounts etc. In complexity it's barely a 'homework assignment' type website, really.
The server isn't currently doing anything with IIS right now (there's even a fair chance that IIS hasn't actually been installed on it yet), so upgrading or altering IIS on the server would be an option, if it's possible. We could also make minor changes to the ASP code if necessary.
Is there anything I should watch out for? IIS and ASP are not my usual battlegrounds, and unfortunately we don't have the time or budget to bring in a specialist 'just' for this particular job.
I don't think you have anything to worry about. A lot of ASP classic applications has been deployed to IIS 5 without a hitch (In fact, I think IIS5 was the de-facto webserver from Microsoft when ASP Classic had the highest adoption).
The only thing I can think of to watch out for, is if the application uses any non-standard or new COM objects, that is not present on the Windows Server 2000 box.
I would like to hear if there is a small classic ASP server, similar to the ASP.NET Development server that comes with Visual Studio?
We are a small group that supports a legacy (classic) ASP site, and would therefore like to have a small server that easily can be executed on a Windows XP machine. Currently we're stuck with IIS 5.1 on our development machines (and because we're running XP Pro, we cannot update to IIS 6 or 7).
I've tried installing the Cassini web server, but that doesn't seem to work with classic ASP either.
You're not going to get anything extra from ASP by running on IIS 6 or 7. Are you having any specific issues with being stuck on IIS 5.1?
Have you tried Baby Web Server? - http://www.pablosoftwaresolutions.com/html/baby_web_server.html
The short answer is No, there is no small web server that runs classic ASP. There are many alternatives, as mentioned here, such as IIS or Apache plug-ins, but none that has a similar small footprint like the ASP.NET Development Server that comes with Visual Studio and that supports debugging.
There is a small footprint web server that runs Classic ASP.
Its called Abyss Web server. Abyss Web server is produced by Aprelium software and can be downloaded free of charge. Abyss Web server can be configured to run with ASP.net OR Classic ASP.
The Server can be configured to run ASP.net without any addition downloads.
To run Classic ASP on the server a program called ActiveHTML written by Selisoft must be downloaded and configured to allow Classic ASP to run on the Abyss web server. Active HTML is on a 45 day free trial and if you like it the purchase price is currently around 30 to 40 euros depending on whether you need a client or server version.
Hope this helps.
Anthony
Abyss web server http://www.aprelium.com/ supports classic ASP (also ASP.Net, Ruby, and PHP) with a 3rd party extension that cost $$$. But at one point there was a free version of the third party component, you MIGHT be able to find a copy of that still floating around. Not sure about debugging.
Baby ASP Web Server can take care of things for you, PLUS you don't have to install it, so it doesn't plop all sorts of crazy settings into your registry.
Get it here
Your only real choice is to either run Windows server or Vista in order to get the latest version of IIS.
Cassini doesn't support classic asp.
According to this post it is not possible to run ASP on Cassini. A couple of google searches later I have still not been able to find any other alternatives either.
What functionality is it that you're after? If it is the quick-and-easy running features of VS, you can quite easily make the IDE debug on IIS (although ASP cannot technically be "debugged" - what you really do is just run it with the Ctrl+F5 command).
Here is a web site that allows you to run classic ASP pages from any web server (including IIS and Apache), but it costs money:
http://www.selisoft.com/en/ahtml/index.phtml
Currently our dev team set up all the websites they're working on in IIS on their local machine. We're thinking of switching to using the built in ASP.NET development server instead.
Is this a good idea? What are the pros / cons of using the ASP.NET dev Server? Are there any gotchas we should be aware of?
Thanks.
NB: Running on Win XP / IIS 5 / VS2005
Edit:
Didn't realise it was called Cassini.. More answers for Cassini v IIS here.
There is nothing that the ASP.NET Dev WebService can do that IIS can't (You can set breakpoints etc, just attach the VS debugger to the ASP.NET runtime).
However, the ASP.NET Dev WebService does not represent a true production environment, and as such you can get caught by gotchas that you wouldn't expect when you deploy to production.
Because of that, I mandate that all development is done using IIS on a local machine. It doesn't take much work to configure a site in IIS.
It's a very good idea. Here are some reasons for:
You no longer need admin access to your machine for web development (it can still be helpful).
It's much easier to test a quick change and continue work, and faster iteration cycles are good.
It can simplify setup and deployment of your development environments.
The XP version of IIS has limitation that are not present in the Server version that Cassini side-steps.
The only argument I know against is that there are a couple very rare edge cases where the Cassini built-in server doesn't exactly mimic IIS because you're using odd port numbers. I doubt you'll ever run into them, and using Cassini as the primary dev environment does not preclude developers from also having access to IIS on the machine. In fact, my preferred setup is Cassini first for most small work, then deploy to my local IIS for more in-depth testing before moving code back to the shared source repository.
[Edit]
Forgot about url re-writing. You do need IIS for that. And an example of a limitation of the built-in XP IIS is that you are limited to one site in XP (can have multiple applications, but that's a different thing).
I had to switch (back) to IIS for one project, because I needed to set some virtual directories which is not possible on the ASP.NET Development Web Server.
As I stated here: https://stackoverflow.com/questions/103785/what-are-the-disadvantages-of-using-cassini-instead-of-iis your developers need to be aware that Cassini runs as the local user, which is typically an admin account for developers. The development will be able to access any file or resource that their account can, which is quite different from what they will see on an IIS 6 server.
The other thing that's a pretty big gotcha is debugging web services is much easier using IIS and vdirs rather than separate Cassini instances.
I know at one point I had an issue with Authentication not working as expected on Cassini (built in development server)
Also, if you need to test things like ISAPI plugins (a re-writer for example) I'm not sure how that's done on Cassini.
The constantly changing port is also rather disconcerting to me. Also, for each web project in your solution it fires up another instance of a Casini server, and each one takes anywhere from 20 to 50 MB of memory.
I use IIS all the time, it's pretty easy to setup, and you guys are already doing that...
I've used both methods and I prefer having IIS locally vs. using the built-in server. At very least you're more consistent with the final deployment setup.
Also, when using IIS 5.1, be sure to get JetStat IIS Admin, it adds functionality that is disabled out of the box on IIS 5, such as being able to setup multiple sites.
I have run into the following limitations with the asp.net dev server:
does not support virtual dirs. If you need them in your app, IIS seems to be your only choice
Classic asp pages dont run in dev server. So if you have a mixed web app (like I have at my client right now), IIS seems to be the solution
If you need an admin UI to configure settings, IIS works better
Of course IIS requires that you be a local admin.
Another distinction I noticed is that Cassini runs as a 32-bit process and you have no control over it, whereas you can control the application pool of your IIS app to disallow 32-bit (assuming your IIS is running on a 64-bit server). This becomes especially important if your web application is going to call APIs in 64-bit processes such as SharePoint Foundation/Server 2010. When you debug your web app with Cassini as your debug server, you'll get "The Web application at url could not be found. Verify that you have typed the URL correctly" type errors when instantiating objects. If you debug using IIS with the app running in an app pool that runs as 64-bit with an identity that allows access to sharepoint database then you'll be able to debug properly.
In VS12 the development server is way slow, takes a few seconds to download a 2kbyte file. This did not happen in vs10. When you have a bunch of jquery files and css this is a real problem. Also every page requeries all the css/js files. Very very slow regression testing.
The main issue I've run into with the dev server is SerializationExceptions with custom security principals stored on the thread context. Details here.
After deploying a new build (mostly changed DLL's) of an ASP.NET web app the CPU on the server is now jumping to 100% every few seconds and the culprit is lsass.exe. Do you think that the deployment of the asp.net web app to the server and this problem are related? (or a coincidence that it happened at the same time?)
More info:
This is the first time that I've done the build on a Server 2008 x64 machine. Previous the builds were done on a Server 2003 x86 machine. Target is "Any CPU" so should work on either. Deployed to server is Server 2003 x86.
I've searched the web for more info on this and have confirmed that the process is lsass.exe (first character a lower case L and not an upper case i) so ruled out the virus version. Found some docs relating to a Server 2000 bug but doesn't apply here.
I eventually isolated the problem to an ASP forum running "under" that ASP.NET web app. Using the admin page on the forum I took the forum down and then brought it back up again and the problem disappeared. I find this very frustrating because the problem has now gone but I don't know what caused it and as such it could easily return.
I also installed this Microsoft Hotfix and rebooted this server but that didn't work.
Have you checked the System and Application event logs for anything unusual?
Have you updated to use Active Directory role provider? I've seen issues where enumerating groups to do role checking pegs the CPU and really slows down the app. I actually implemented a customized provider that allowed me to specify a particular OU and set of groups that I actually care about to get around this issue.
The xperf tools distributed in the Windows Performance Toolkit will tell you exactly what is usin CPU time or disk bandwith. These tools are free and work on any retail build of WS2008 or Vista. Here is series of posts on the xperf tools from myself.
Occasionally, I find that while debugging an ASP.Net application (written in visual studio 2008, running on Vista 64-bit) the local ASP.Net development server (i.e. 'Cassini') stops responding.
A message often comes up telling me that "Data Execution Prevention (DEP)" has killed WebDev.WebServer.exe
The event logs simply tell me that "WebDev.WebServer.exe has stopped working"
I've heard that this 'problem' presents itself more often on Vista 64-bit because DEP is on by default. Hence, turning DEP off may 'solve' the problem.
But i'm wondering:
Is there a known bug/situation with Cassini that causes DEP to kill the process?
Alternatively, what is the practical danger of disabling Data Execution Prevention?
The only way to know for sure would be to dig through the Cassini source and see if there are any areas where it generates code on the heap and then executes it without clearing the NX flag.
However, instead of doing that, why not use IIS?
EDIT:
The danger of disabling DEP is that you open up security holes. DEP works by not allowing arbitrary generated code on the heap to be executed. This helps prevent malware programs from inserting code into the data segments of legit programs.
You are on vista, iis got better (7), cassini stayed crappy.
So just start this app on iis with a host header and a hosts file entry.
You can grant certain programs exclusion from DEP if you need.
As Jonathan
mentions this does open up any vulnerabilities that application may have.
Using IIS in Visual Studio isn't the pain in the ass that it used to be in 1.1/VS02/03 days. There are lots of good reasons to prefer IIS over the Cassini server (articles by Dominick Baier):
Cassini considered harmful
Another Reason why I would not recommend Cassini
Dominick is 'the man' when it comes to IIS and security stuff.
When using IIS for a web app, I always create the app in IIS first, point it at my preferred folder, then get VS to create the project. This means you don't end up cluttering c:\inetpub\wwwroot with your web apps.
Of course, now we have IISExpress which if you're targeting IIS7.x it's the obvious choice for developing ASP.NET applications in Visual Studio.
Thanks for the answers. I guess I developed such an aversion to IIS in the .net 1.x era that I've refused to consider re-using it -- until now.
aside: when choosing between two equally acceptable answers from ChanChan and Jonathan, I arbitrarily marked Jonathan's as 'accepted' because a) he got in first and b) his rep is currently lower.