I got this recent question concerning the "limitations of ISAPI" as it pertains to mass shared hosting on IIS6.
Hmm... I had to do a double-take because I was not aware of such limitations of ISAPI - in fact, Microsoft has published a mass shared hosting accelerator solution based on ISAPI, as I will shortly explain... so, yup, mass shared hosting is definitely possible with IIS6.
Please tell me the limitations of ISAPI as we are in the process to develop ISAPI filter for Scalable Windows Hosting . We are having around 80,000 websites, migrating from Unix(Zeus) to Windows (IIS6.0) sever. As we will be having some dynamic sites which use CGI-Perl scripts.
As single IIS server can only host around 20,000 sites so we are creating a ISAPI filter so that we can use virtual directory concept and can host sites as virtual directories (as many as we want ) . But will it be good if we are planning for ISAPI (Performance) and does ISAPI(IIS) support dynamic sites which will be having CGI-Perl scripts.
Please give your suggestion and inputs on this,It will really be very much helpfull for me to carry out this migration process.
Thanks and Regards
Hey now... let's first get into the right mindset: IIS 6.0 and Windows Server 2003 is more than scalable and performant enough to handle your scenario. :-) You just have to get a couple of non-obvious things straightened out:
I am glad to assist and point you in the right direction on this endeavor
First off, I want to say that you had to do the same sort of customization with other web servers like Zeus or Apache since VHosting is not default and requires new directives and configuration. The key difference here is that there were well known modules and configuration for Zeus/Apache to do this.
Well, now there is a similarly "well known" module to do the same for IIS... in the form of Windows-based Shared Hosting Accelerator (I swear I am not involved with the naming of any of these things; I am just the messenger ;-) ). Actually, it is closer to a whole set of solutions and pre-developed code, one of which is the ISAPI Filter that you are talking about implementing (but we have already implemented it and added several extensibility points to it that you can probably quickly take advantage of, like custom-authentication). I have pinged a couple of people internally and hopefully they will be contacting you soon (they are all currently on vacation until the end of the month).
As for dynamic sites... that should not be a big problem as long as you stick with an ISAPI implementation of Perl that fits your functional, performance, and reliability requirements.
I think the key thing you want to do when migrating across platforms is to make good effort to take advantage of the new platform. I think the worst thing is to simply take what "has always worked" and try to make it work on the new platform - that is like bringing over old baggage which will inevitably slow you down, and you never realize the benefits of the new platform.
Now, I am not advocating that you simply throw everything out and start over; I am simply suggesting that you look at the advantages of the new platform and write new code/processes to take advantage of them, while simultaneously try to re-use as much of the existing code base (possibly small tweaks here and there).
For example, when choosing between ISAPI and CGI, always choose ISAPI for IIS. Why?
As for how you want to provision all of the websites... here is how to think about it all.
However, it is very possible to utilize Application Pools to partition the URL namespace - you just have to configure things a little differently due to how the shared hosting ISAPI filter works.
Logically, this is how things are configured, both before and after:
Before (rich bindings)
* Notice how each Host header website needs its own Website ID, AppPoolId, and ROOT/Path.
* This is what is "rich" about the configuration
After (mass hosting)
* Notice how I just aggregated two host header websites onto the same Website ID
* HTTP.SYS will still route the websites to the same Application Pools as before
Mass shared hosting is all about how to pack in websites under W3SVC/1/ROOT using the ISAPI Filter while provisioning the websites between Application Pools for isolation as shown by W3SVC/2/ROOT/AppPoolId. You essentially only need as many dedicated IIS Site Bindings as you wish to partition with Application Pools. So before, you would have needed 20,000 Site IDs isolated by 10 application pools (and IIS6 would scale like 20,000 websites)... while after, you only need 10 Site IDs each corresponding to a different application pool, and the ISAPI Filter routes the websites from HostHeader to vdir (and IIS6 runs like 10 websites).
With clever server configuration and ISAPI Filter code, you retain all Application Pool isolation benefits at low cost from the point of view of a rich IIS Site Binding.
If you have any questions, feel free to tack on Comments for the benefit of all readers.