Single vs. multiple installations of same web app

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Joern Schou-Rode

    Single vs. multiple installations of same web app

    Hi all,

    I am working on a project where we need to host a growing number of web
    sites (initially around 15). In terms of functionality the sites are
    identical, and the only differences lies in some application settings (UI
    language, layout template, etc.). Thus, we are really talking about one
    web application, installed and configured to run under several
    "identities ".

    It seems to me that two alternative approaches exists on how to tackle
    such a setup, but I am having a hard time choosing the right one to go
    with. Let me explain the options as I see them:

    A) Build a single web application and install it once for each "identity"
    (= hostname).

    Pro: Application settings goes in web.config.
    Pro: Each site will have its own IIS log file.
    Con: Changes must be distributed to all instalations.
    Con: Seems redundant to duplicate code on server.
    Con: Overhead in loading the same app several times.

    B) Build a single web application and install it just once on the server,
    with binding to all hostnames.

    Pro: Updates/changes to be installed just once.
    Pro: Ensures that all sites are code-wise up-to-date.
    Con: Requires some custom configuration API.
    Con: Configuration errors etc. might break all sites.

    Do you have any experience with the kind of setup that I am talking about?
    Do you have anything to add to my list above? Do you have any other advice
    that might be useful for me to make the decision on which path to follow?

    Thanks in advance.

    --
    Joern Schou-Rode

  • Anthony Jones

    #2
    Re: Single vs. multiple installations of same web app

    "Joern Schou-Rode" <jsr@malamute.d kwrote in message
    news:op.uf6dhmj m31zpn8@marvin. ..
    Hi all,
    >
    I am working on a project where we need to host a growing number of web
    sites (initially around 15). In terms of functionality the sites are
    identical, and the only differences lies in some application settings (UI
    language, layout template, etc.). Thus, we are really talking about one
    web application, installed and configured to run under several
    "identities ".
    >
    It seems to me that two alternative approaches exists on how to tackle
    such a setup, but I am having a hard time choosing the right one to go
    with. Let me explain the options as I see them:
    >
    A) Build a single web application and install it once for each "identity"
    (= hostname).
    >
    Pro: Application settings goes in web.config.
    Pro: Each site will have its own IIS log file.
    Con: Changes must be distributed to all instalations.
    Con: Seems redundant to duplicate code on server.
    Con: Overhead in loading the same app several times.
    >
    B) Build a single web application and install it just once on the server,
    with binding to all hostnames.
    >
    Pro: Updates/changes to be installed just once.
    Pro: Ensures that all sites are code-wise up-to-date.
    Con: Requires some custom configuration API.
    Con: Configuration errors etc. might break all sites.
    >
    Do you have any experience with the kind of setup that I am talking about?
    Do you have anything to add to my list above? Do you have any other advice
    that might be useful for me to make the decision on which path to follow?
    >

    A)

    The distribution of common files could easily be automated from a single
    master. With that in place I can't see much of a draw back to redundant
    code. If you are doing ASP.NET place as much code as possible in dlls in
    the bin folder. You could take that a step further by placing some code in
    the GAC which will eliminate the redundancy for those dlls (which gives you
    better JIT performance ). However only do that for slow moving utility
    code.

    There are some advantageous to having these sites run as separate
    applications, isolation is one. Failure in one doesn't affect the others.
    You can take down one with out taking them all down. You can roll out
    version upgrades rather than be forced into a big bang roll out (although my
    GAC suggestion may act counter to that).

    If the app runs as a 32bit process then memory can be utalised better having
    separate apps especially if the app uses session data since a web garden
    would break that.

    Also there is nothing 'clever' going on that is outside the norm. The
    nominal path should never be underestimated its the most well trodden and
    therefore the most tried and tested.



    --
    Anthony Jones - MVP ASP/ASP.NET


    Comment

    Working...