I have a client with a large ASP app that apparently is fairly memory intensive. I’m helping them migrate to new hardware they have running Win2k8 R2. They have 4 physical servers with 32gb of RAM each. I’m making the assumption that ASP apps run as a x32 process. So I see that we have two options:
On the application pool enable web gardens.
Use the physical servers as VM hosts and split the box into say 4 web servers each.
Any thoughts on which path will provide us better performance? I’m just not really sure how ASP will handle a machine with lots of memory, and I’m worried it won’t really be able to address the memory well. (you can ignore all the obvious stuff like increased maintenance of 16 web servers vs 4, or the flexibility virtualization gets us over physical servers, etc)
It doesn't necessarily follow that an ASP app will require a 32bit process. The common APIs such as ADODB are available in 64 bit so there is a possibility you could run it in a 64 bit process which is certainly worth pursuing first.
When it comes to Web Gardens and ASP if the ASP application makes use of the Session object then you are in trouble. Unlike with Windows Load Balancing there is no way to affiliate a session with a specific process. So if you do need the Session object that just leaves you with VM hosts.
If you can run without Session object the a Web Garden approach is going to be better than multiple VMs.
You might want to double check that assumption about 32 bits: See also this question
Related
I'm considering migrating to SQL CE 4.0 for my website projects, all of my sites use Umbraco but they aren't seriously busy websites (up to 15,000 visits month).
My main concern is performance, so I was wondering if anyone had any experience or knowledge on what sort of performance limitations I can expect.
Also, if running in a managed host environment do I need to be concerned about application pool memory limits?
Thanks
The performance of the website should be no problem, because it reads all from cache.
But I'm having trouble with the CMS performance, on my local environment but also on my VPS and on a shared hosting environment. It takes a lot of waiting time before items are created and edited. That's a big issue for my customer right now.
I do run the latest version of Umbraco (4.7.2.1) which should include a lot of performance improvements for SQL CE.
It might get even worse when the datbase size is growing (mine is about 92Mb)
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've read recommendations that we should create separate application pools for each asp.net application on our Win2008 server.
We have about 20 apps that would be on the same server. I know this would create 20 separate worker processes which seems very wasteful.
Is it good practice to create separate application pools for each application?
Reposted from ServerFault, "Why add additional application pools in IIS?"
AppPools can run as different identities, so you can restrict permissions this way.
You can assign a different identity to each app pool so that when you run task manager, you know which w3wp.exe is which.
You can recycle/restart one app pool without affecting the sites that are running in different app pools.
If you have a website that has a memory leak or generally misbehaves, you can place it in an app pool so it doesn't affect the other web sites
If you have a website that is very CPU-intensive (like resizing photos, for instance), you can place it in its own app pool and throttle its CPU utilization
If you have multiple websites that each have their own SQL database, you can use active directory authentication instead of storing usernames/passwords in web.config.
Separating apps in pools is a good thing to do when there's a reason, and there are a number of good reasons listed above. There are, however, good reasons not to separate apps into different pools, too.
Apps using the same access, .NET version, etc. will run more efficiently in a single pool and be more easily maintained. Most annoyingly, IIS will kill idle app pools, requiring the pool be recreated on each use. If you isolate infrequently used apps you'll impose an unnecessary startup cost on users. Combining these apps into a single pool will make for happier users when they don't pay the startup cost, happier servers when they don't give memory to multiple processes and CPU slices for them, and happier admins when they have to manage fewer app pools.
I used to have 58 .Net websites and 17 old classic ASP websites on the same IIS7.5 server using separate app pools for each site. I noticed that the IIS compression started failing intermittently, causing the style sheets to be corrupted about 5% of the time. Looking at the task manager on the server, I could see that the server was approaching it's 4GB ram limit- each w3wp.exe process was taking anything up to 100 MB memory depending on how much traffic the site was getting. I then moved all the websites into just 2 application pools (one for .net 4 websites and one for the old classic ASP sites) and the total memory used after doing that dropped from 3.8GB to just under 2.8GB - saving me over 1GB memory space on the server. After the change (and leaving the server running for a couple of hours to get back to normal levels of traffic), the w3wp processes were using 300MB for all the .net websites websites and 20MB for the classic ASP websites. I could re-enable IIS compression again without a problem.
Using separate APP pools is a great idea for many of the reasons mentioned by the other posts above, but it also in my experience causes a much higher memory overhead if you are hosting a fair number of websites on the same server.
I guess it's a trade-off between hardware restrictions and security whether you want to use separate app pools. It's a good idea if you have the resources to do it.
yes, it is a good idea even for 20 applications.
Security. Different app pools running under different accounts.
Isolation. One crashing app won't take down other apps.
Memory (if you are running 32bit). Each app pool will have its own address space. Thus you can address much more memory than a maximum of approximately 2.7GB of usable space for 1 process.
You may choose to periodically restart one not-so-well behaving app without affecting other applications.
If your apps are stable and don't use much memory, then I would say that it's fine to put them in the same app pool. App Pools give you isolation between your applications.
One main reason I consider when creating app pools is the process management. There are other reasons such as security etc.
When an IIS-hosted application crashes it takes down its host process as well. In previous versions of IIS this meant all web activity crashed together. With app pools you can isolate your applications from one another. If one has a memory leak and keeps crashing your other apps will continue to function.
The main benefit of creating different application pools is that you can provide each pool with other credentials. Your 20 applications may communicate with 20 different databases that all need another login. The best practice then is to run each application using a different service account.
I wouldn't worry too much about performance. Most time will probably be spent inside each web application, no matter what process each application is in.
This really depends on the applications, your security model, and how much you trust the applications.
Here are a few things that I always tell people to consider when working with application pools.
Use separate application pools if each application needs different access to system resources. (Can use multiple process accounts)
If an application is a resource hog, mission critical, or an "unknown", it is best to put it in to its own pool to isolate it from the rest of the system
We work as outside contractors for a large corporate client. We are not on-site, so we do not have connectivity to all of their systems. Sometimes during development it is necessary for me to debug an application directly on their development servers. To do that I must be able to attach to w3wp process. When I attach and start debugging, entire process stalls, which affects all of the applications that are in the same process/application pool.
By creating a dedicated application pool and moving my development there, I can easily debug without making anyone's life miserable.
Working with one of our partners, we have developed now two separate sets of web services for their use. The first one was a simple "post to an https URL" style web service, which we facilitated by building a web page in ASP.NET that inspected the arguments in the URL, and then acted accordingly. This "web service" (if you can call it that) has been very stable.
At some point, the partner asked us to begin using SOAP based web services. At their request, we built them a new set of web services largely based on the previous objects, reimplemented as an actual "Web Service". This web service has not been very stable: around once a week, Nagios will alert us that our web service is not responding - and a quick iisreset does the trick.
Analyzing the log output and working in a debugger has not led us to anything concrete. The volume on this new web service is actually much lower than the HTTP web service. I think this could be a code problem or a platform problem, or of course something in between.
We've tried, with little improvement:
To duplicate the behavior in the lab
Debugging in the Visual Studio debugger
Tinkering with IIS options to give it its own application pool
My question, what are the next steps for troubleshooting?
Environment:
Windows Server 2003 Standard Edition R2 Service Pack 2 32 bit, Visual Studio 2005, MS SQL 2005, .NET Framework 2.0.50727
You may get some answers by profiling your webservices and understanding how they are using their resources. perfmon and procmon are both very useful tools in this regard.
EDIT: Since you say errors happen after about a week, the only thing I can think of is resource usage. Ensure your DB connections are being cleaned up, and any opened files (system call to the exe) are being closed.
Also, if your webservices can tolerate it, IIS has a setting that triggers a periodic recycle of an App Pool to handle cases where performance degrades over time. Its dirty, but it may work well for your case.
Since there isn't much to go on - here's another odd issue we came up against regarding our web services.
When the web service stops responding how is memory utilization? We have experienced issues with memory and memory fragmentation relating to busy web services on a system (there was also other things running causing additional fragmentation). When we re-factored the web services to load from smaller dll's and depend on other libraries (instead of one large library) we were able to resolve the memory fragmentation.
To identify what was occurring we would take a dump from the offending iis worker process where the app pool resided and then reviewed that using WinDbg.
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Additionally we used DebugDiag to take the postmortem dumps.
http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1286
Hope this provides another direction to look at.
What are pros and cons of having dedicated application pools over keeping web applications in one default app pool?
Pros:
Applications are isolated from each other, unless IIS goes with it, an app pool locking will only take out applications in that pool
Ability to run applications under different ASP.NET runtimes, one pool for 1.1 another for 2.0 if needed
Ability to have different app pool settings for more or less critical applications. For example a corporate website in ASP.NET might want to have the shut down after __ minutes of inactivity bumped up, to prevent unloading because response is critical. Other sites might not need it.
Can secure pools from each other in regards to file access, great for third party, or untrusted applications as they can run under a very restrictive user account.
Cons:
Each application pool has its own bank of memory and its own process, therefore CAN use more resources
Some find it hard to debug the application as you have multiple processes
The primary reason for combining sites in app pools is to conserve memory. There's a large memory overhead in running several w3wp.exe processes. If you have no specific reason for splitting them up, it's better to keep them together.
Dedicated app pools typically will keep problems occurring in one site from effecting the others. If you share app pools across sites, you could bring down all sites on the box when an error condition exists for only a specific site (or app pool).
Also, if you are mixing versions of ASP.Net on the same web server, you will need different app pools per ASP.Net version at a minimum, or do it per website.
I can't think of a good reason not to separate app pools, it is so easy to do.
I agree with Jason.
Also, you can designate different users (such as a Windows account) for different app pools. That enables setting up those users with different permissions in the database. That helps enhance security, and enables tracking which website/user is hitting the database, useful when tracing database performance issues.
If you have separate apppools then you pay a penalty in the initial load time of the first person to visit your site and spin back up the apppool after it recycles.
For example let's say overnight no-one hits your server, IIS will spin down (default 20mins I believe). The first person to visit the server will suffer a delay until the your application has been loaded back into memory.
Depending on how you deploy your site (e.g. release mode etc..) this will either not be a problem or could be annoying.
This is why we are looking into moving to a single apppool/server rather than 1 for each site.