Application structure for NLB

[J. Baute]

Hi,

we're looking into addapting an intranet site to make it possible to load
balance it.
Currently is consist out of 3 major parts which are
1) the code
2) the database with system data & user content
3) html & picture files uploaded and maintainde by users (site content)

Currently the application is split up into to parts, where we have a backend
DB server, and code & content are on the webserver.

N° 3 is where we have a "problem". Since this content is variable, this
needs to be available on all NLB'd webservers.
Basically it would come down to moving the content, which is now hosted on
the webserver itself, to the backend DB server (or another server), so that
all NLB'd server are always accessing and updating the same shared data.

The thing is that by doing this we are actually putting more load on the
backend server, which will now also be in charge of hosting the files,
indexing them, together with the serving the DB, and the NLB'd webserver
will only be running the code.
So in fact, the part that will be load balanced, will be the least intense
part. The bottleneck will be the backend server... so maybe it's not worth
the trouble of LB'ing the whole thing?

Thoughts, comments?

 

[J. Baute]

Hi,

we're looking into addapting an intranet site to make it possible to load
balance it.
Currently is consist out of 3 major parts which are
1) the code
2) the database with system data & user content
3) html & picture files uploaded and maintainde by users (site content)

Currently the application is split up into to parts, where we have a backend
DB server, and code & content are on the webserver.

N° 3 is where we have a "problem". Since this content is variable, this
needs to be available on all NLB'd webservers.
Basically it would come down to moving the content, which is now hosted on
the webserver itself, to the backend DB server (or another server), so that
all NLB'd server are always accessing and updating the same shared data.

The thing is that by doing this we are actually putting more load on the
backend server, which will now also be in charge of hosting the files,
indexing them, together with the serving the DB, and the NLB'd webserver
will only be running the code.
So in fact, the part that will be load balanced, will be the least intense
part. The bottleneck will be the backend server... so maybe it's not worth
the trouble of LB'ing the whole thing?

Thoughts, comments?

anyone?

 

[Chris Hohmann]

"J. Baute" <[email protected]> wrote in message

anyone?

This is interesting. I was having a discussion recently about this very
topic. An associate of mine was arguing that we should store images,
reports and other object within the database to provide "location
agnostic" access to the files for a web farm scenario. I argued that
it's seldom appropriate to store object in the database and would rather
see references to those files stored in the database or simple use a
virtual directory mapping to provide mirrored access to the same file
share to each web node. So you can either:

1. Store the files in the database. Boo!

OR

2. Use virtual directories to provide mirrored access. Good but not
great

OR

3. Use virtual directories in combination with file references stored in
the database. Great! The best of both worlds.

HTH
-Chris Hohmann

 

[J. Baute]

This is interesting. I was having a discussion recently about this very
topic. An associate of mine was arguing that we should store images,
reports and other object within the database to provide "location
agnostic" access to the files for a web farm scenario. I argued that
it's seldom appropriate to store object in the database and would rather
see references to those files stored in the database or simple use a
virtual directory mapping to provide mirrored access to the same file
share to each web node. So you can either:

1. Store the files in the database. Boo!

OR

2. Use virtual directories to provide mirrored access. Good but not
great

OR

3. Use virtual directories in combination with file references stored in
the database. Great! The best of both worlds.

N°3 sounds like the best solution to me as well, and is basically how
I'm thinking of implementing it. File references are already stored
in the database as partial URL's to a now fixed content directory, but
that can easily be made into a virtual directory without having to
change any hyperlinks in the app itself,

which is nice