When I deploy my ASP.net 4 website on newly installed IIS 6 on Win Server 2003 R2 or on IIS 7 on Windows 2008 R2, I have a very good (actually instant) access to my website pages while calling them locally, but while trying to access them from any other intranet computer, the speed slows down very badly and I can not find what is the problem. It has been become a major problem for me and my job and I've been looking for a solution but I've not detected any solutions already. Would you please helping me?
By the way the users of this website will be at max 20 persons and I've deployed my app on a very very powerful dedicated server with about 64GB of RAM and 16 CPU cores.
Thank you so much.
This could be created by many different things such as:
Incorrect IIS configuration
Incorrect Routing
Database Latency
Server Over utilization
I would start by seeing if a static HTML page with no code is delivered quickly. If yes then I would look at using ASP.NET Tracing as a starting point to see where the problem in the code may be. If No then I would look at the IIS and routing configuration for your network.
I changed to forms authentication and I am getting very good speed results.
Related
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.
I have 17 simple data entry applications(.net version is 3.5, designed in asp.net, coding language is c# and database is Oracle 10g) hosted under one application pool which is configured on IIS7 as .Net Framework Version = v2.0, Manged pipeline mode = Classic. My server is Windows server 2008 r2 64 bit with 32 GB ram.
Problem is one of my application started responding slowly, it was working fine before but now even pressing the tab key takes 2 to 3 seconds.
To check the problem I debugged the application in visual studio 2008 and it was working fine, then I configured the IIS7 on my PC and hosted the application from it and it was working fine( surprisingly my pc only have 4GB of ram and 32 bit windows 7 as operating system.)
I also tried DebugDiag on server to check the performance of w3wp.exe but couldn't find anything.
I also compared both the hosted applications (one from my local PC and one from server) using Firebug and fond under the .net tab that application hosted from server is taking more time, but I don't know the reason.
I also know for sure that database is not responding slow.
If someone can advice me how to check the problem that would be great,any advice would be appreciated.
Many thanks.
I developed a project in ASP.Net MVC 3, my hosting is using iis7 (Win Web Serv 2008 R2), and the first request after the website sit's idle (during about 1-2 hours) is very slow.
I use VPS with 512Mb RAM. Can this be related with a too little RAM?
Can anyone help me with possible causes of such behaviour?
After a certain amount of inactivity IIS unloads the AppDomain. And then the first request loads the application once again which is slower. You could try to configure this period in the properties of IIS but there might also be other causes that an application unloads such as for example a certain threshold of CPU or memory usage is reached. Those thresholds are also configurable in IIS.
That's not something specific for ASP.NET MVC. It's true for all ASP.NET applications in general.
We had also this problem with ruby and passenger that takes the app out of memory after a while, but I found a nice application that fixed this issue for us without changing anything in the server configuration, the app is called wekkars, and you can find it here: http://www.wekkars.com
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.
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.