What is the limit of IIS 6.0? like for example if i need to host 100,000 or 200,000 websites on IIS 6.0, how many machines would i need? or is IIS7 would be a better choice in this case for some reason?
As mentioned in the comments above the scale isn't so much the number of websites you create in IIS, but how complex and how busy those sites are.
In IIS6 one website does not necessarily equate to one executing process on the server. Application pools can group multiple websites into a single executing process to group and/or isolate applications. Alternately a single app pool can spawn multiple executing processes to make better use of server hardware.
It might help if you were to provide more detail in your question about what exactly you're trying to accomplish. If you're going to be serving hundreds of thousands of sites it would probably be a good idea to partner with a hosting company, or get some assistance from someone who knows the ins and outs of IIS, or another platform in detail and has operational experience with working through large-scale hosting scenarios.
IIS7 is not radically different from IIS6 in any performance-related way; with one exception: you can run ASP.NET in a "native" pipeline mode that bypasses some processing steps. I prefer IIS7 (if I can choose) because of its manageability advantages. But like everyone else said here: the question is impossible to answer without more information.
Hosting that many websites with IIS will be cost-prohibitive in licensing fees. Most large scale web hosting is done on Linux using Apache.
Related
Is it applicable to have both SharePoint 2013 and Sitecore 8.2 installed on the same servers (sharing the same Infrastructure)? If yes, is there any drawbacks?
Thanks for your appreciated help in advance.
Technically speaking it is safe, but both will make usage of IIS infrastructure to deliver their websites, and the machine hosting will take its toll on memory and possibly disk I/O depending on how any of these products were configured to store their data.
I had the unfortunate "pleasure" to work with Sitecore 7 and 8, and I can guarantee you it is possible and somewhat safe, but there are conditions to meet, let me go over some possible red flags here and it will hopefully help you to make a more balanced decision on how to set up both products on the same infrastructure.
The first scenario and the safest: 3 SERVERS
SQL Server with two instances, segregating SharePoint and Sitecore
One server for SharePoint (assuming it is a single farm server)
One server for Sitecore (assuming you can handle search/indexing altogether)
This is the best and the safest, since IIS is the tug of war if both SharePoint and Sitecore reside on the same server, on the scenario above SQL Server can deal with both on the same instance if you don't mind access restrictions/security, but it is better to go on distinctive instances, will be safer and easier to administer
The second scenario: 2 SERVERS
SQL Server with two instances, segregating SharePoint and Sitecore
One server for SP + Sitecore
Yes you can have both but you will need to configure ports, sites, application pools and hardware requirements very carefully.
Some considerations:
Microsoft has made clear how SharePoint should be configured, you need a dedicated machine for SQL Server, anddifferent SharePoint servers according to their specific roles in a farm: Web Front End, Application Server, Search Server, etc. or if it is a very small "farm", you can cram all of them into one server but the SQL Server (this is where disk I/O is the king of the hill).
While Sitecore doesn't not need a farm like SharePoint it shares the same similarity, a dedicated server for SQL Server, one server for Sitecore and in some cases you will like to have another server for Search and Indexing.
The bottom line here is, all depends on how big is your project, and size here is measured in the number of factors: number of users, simultaneous users, volume of data stored.
I would not mix SharePoint and Sitecore on the same machine but I would not mind at all to mix them in the same SQL Server in different instances, the reason is simple, SharePoint is more likely to take a hold of IIS, assuming you are running SP 2010/2013, the User Profile Service and the FIM are a common cause of trouble in the SharePoint realm, and it is common for SP Admin to perform IISRESET -NOFORCE to troubleshoot cases like these.
If you are using Sitecore + MVC or MMVC, you might end up customizing the IIS Sites with some heavy loads and you will need to beef up the machine to not bring SharePoint down (assuming the SharePoint Central Admin and SharePoint Web Services + additional User Web Applications you have created) are all there installed on the same server.
I'm trying to not make this overly complicated but sharing some real world scenarios because it all boils down to the load on the server, you need to remember one thing, SharePoint is a beast and it is the one that will need more resources if you want a Single SharePoint Server + Sitecore living on the same place, got it?
The recommendation from both Microsoft and Sitecore is clear: dedicated servers, and anything beyond this is at your own risk.
I've mixed and placed both together, it worked for me but I wouldn't do this again, it is not worth if have the chance to keep them apart.
I agree with Dr. Sushi on all his points. One other thing to consider is the Sitecore licensing limitations. If you are using a persistent license (a.k.a. server license) most of them limit you to 8 cores on the server. If you are running both Sitecore and Sharepoint on the same server you might need to go beyond 8 cores to handle production load, which means now you have to buy multiple licenses for Sitecore for that single installation, or you have to switch to a subscription licensing model.
Hopefully my question is in the right forum here. I've just checked out the pricing model of windows azure and checked out the different configuration options:
http://www.windowsazure.com/de-de/pricing/calculator/
I have been working as a developer for almost two years now and worked a lot with IIS and the WPF technology. As a little private project I checked out HTML 5 and JS with MVC4 Web API and wondered what azure configuration I'd need to host a MVC 4 Web API project. Would it be rather a virtual machine or a full calculator? What benefits grants one over another?
I am going to start my studies soon, so I'd like the cheapest I can possibly get. I won't use it a lot (mainly for testing reasons), as well I think there won't be too much traffic either. Would a virtual machine also include the possibility of using IIS?
Could I also run a MVC project with something else than VM/full calculator?
And what would happen if for some reason my traffic just explodes? Would my services just be shut down until I increase the power of my machine? Or would I just get a huge bill and be surprised quite a lot?
Use websites.
You can start with 10 Web Sites absolutely free! So this is the cheapest. And it certainly supports MVC4 Web API.
For starter you can get a 3 month trial with enough credits to start. By default you'll have a spending limit on your account. This mean if you start to get too much traffic your services will shut down and you won't have to pay any extra. I think you can configure how much you are willing to pay but I never tried, it is still the default which is 0$.
You should start with Shared Web Sites and move to reserved instance, VM or web role later if you ever need to scale up or out.
Is there a guideline or site in where I can information about best practices for configuring IIS 7 Application Pools?
Take a look at http://technet.microsoft.com/en-us/library/cc753734(WS.10).aspx for an IIS 7 overview but look at the Understanding Sites, Applications and Virtual Directories section http://learn.iis.net/page.aspx/150/understanding-sites-applications-and-virtual-directories-on-iis-7/
Hard to really put together best practices since each setup is different, however it usually comes down to performance vs security.
The short answer there is to group similar security requirements into the same app pools but don't be afraid to make additional app pools.
We have a legacy system which is build in classic ASP. As we move to asp.net, we find ourselves creating web applications as we migrate old stuff to .net and add new functionalities to the system. I would say maybe 30% of them would share the same library, loading the same dlls. (all applications share the same app pool)
My question would be, what's the pros and cons of this approach?
Would it be better to have one application root?
I am not really looking for a specific answer, just curious what you people do usually and why?
thanks a lot
I would place things that can be logically grouped together into its own app pool.
Example: Components needed for a website or webapp under IIS could be considered a single logical group, therefore it needs its own app pool.
Anything else that is separate should have its own domain with own app pool.
But, IMHO, i think it's a judgment call based on the nature of the app and if it has any dependencies... etc. You know the system better than anybody, so from a 20k foot view of it all, how should things be logically separted?
Example scenario:
If you have an app that needs to be reset via IIS, will it affect others (will others go down due to the one app that requires an IIS reset)? If it's not a big deal, then why not (lump it together with the other). If it is a big deal, then keep it separate so it's not dependent on any externals.
I'm setting up an Internet-facing ASP.NET MVC application, on Windows 2008. It uses SQL Server 2008 for its database. I'm looking for best-practices for securing it.
I found this article, but it's a bit dated now. How much of that advice is still valuable?
Some background -- it's a personal site, behind my home NAT/firewall box; and I'll only forward ports 80 and 443 to it. The IIS server itself is a Windows 2008 host running on HyperV (I only have one physical box to spare).
One useful thing that's mentioned in that article (which had occurred to me already) is that the IIS box shouldn't be a member of the domain, so that an intruder can't easily get off the box. I'll be removing it from the domain in a moment :)
What other tips should I (and anyone deploying to a bigger environment) bear in mind?
I know that this isn't strictly a programming-related question (there's no source code in it!), but I guess that most programmers have to dabble in operations stuff when it comes to deployment recommendations.
You might take a look at these two tools:
Best Practices Analyzer for ASP.NET
SQL Server 2005 Best Practices Analyzer (even though you are using 2008, still might be of help)
I don't know about removing it from the domain, but I'd certainly disable LanMan hashes, keep the system fully patched, and use good password security. Make sure that any processes running in IIS run from least privileged accounts, i.e., don't run the worker processes under IDs that are in Local Administrators.
This will be of great help, certainly:
Microsoft Web Application Configuration Analyzer v2.0