Home / server / Questions / 80633
Accepted
Andrey
Asked: 2009-11-03 10:47:51 +0800 CST

Web application design in case of several sub-applications

  • 772

I'm currently in an early design stage for a large scale web application which will definitely be hosted on a large farm of web servers. Now, I'm trying to decide whether I want the whole site to be a www.site.com and place sub-apps in folders, like www.site.com/blogs, www.site.com/messages, etc. or whether I want to have them as subdomains, e.g. blogs.site.com, messages.site.com etc. The biggest con against subdomains is that I'll be heavily using ajax and it does't like cross-domain calls, e.g. I won't be able to call a web service hosted on www.site.com from a page hosted on blogs.site.com - browser will throw a permissions exception. The biggest con against having everything under www.site.com is that I don't see a way to dedicate web farms to specific sub-apps then. Like if I want a farm to be dedicated to blogs app, then it's easy in case of using subdomains, but how do I do that if everything is under www?

I am probably lacking some knowledge on the networking part of web farm setup so any comments/ideas would be welcomed and highly appreciated!

Environment is Windows 2008 and ASP.NET 3.5

Thanks! Andrey

network-design

2 Answers

  1. You didn't mention the platform but eg with IIS7 ARR you can direct calls to different servers based on a number of criteria like tiny details of the URL, mime/file types and what not so I'd say any decent load balancing product would be more than happy to sort this out for you without sub-domains ^^

    • 1
  2. Best Answer

    Whilst it is certainly easier to split requests into multiple clusters when you use subdomains, good reverse proxies like haproxy and varnish are more than capable of inspecting the URL and deciding where to send the requests. Also, have you considered not specialising servers on the web service tier and just letting every webserver machine handle any request it gets given? This saves the embarrassing hassle of misjudging your capacity distribution, and having to make a panicked move of a few servers from one cluster to another when load shifts suddenly.

    You can still specialise in your backend tier if you like -- clustering databases is a lot harder than clustering webservers, after all -- but by then you've got the intelligence of your web application at your disposal to decide where to make the backend requests to.

    • 1