I am beginning in a project which is a total disaster.
The company has done a lot of things that I don't like so much, but I am an analyst-programmer, so I have not voice for changing anything.
One issue is that all the modules of the different programs are in all the machines of the farm (>100 servers). So the load is balanced between all of them.
I think that this works but isn't a good policy:
1) Perhaps if a program fails It could make all the servers to fall down because it is in all of them.
2) The loads aren't understood, because it is difficult to view which projects are the heavy.
3) Having >100 IISs makes ASP.NET caches being less productive.
4) tiers aren't separated between machines, so if you can't understand the load is very difficult to scalate a module

how to install several programs in farm
hornnick
I have investigated a little about the fourth issue in my company, chiefs told me that separating layers at machine levels give us a big delay because of the communications. Is this normal In your projects... do you separate UI layer and BL into two different machines layers I think in a LAN it must flyyyyyyyyy and will have a little cost (i can assure they haven't tested it).
I think that cost, in monetary terms, can be reduced a lot because w2003 web server is much cheaper than w2003 enterprise, and you can separate the UI work in a little layer which uses a cheaper OS.
Waiting your answer friend!
This is a very good forum for asking things anonymously and learn a lot
Iain Mcleod
KaldorKaldience
Thanks for the response, I am not trying to change it because here in Spain bosses are bosses and don't like to hear any change, but I am trying to learn how it should be ok.
I think that this architecture is a little poor and gives no info to understand what should be improved.
Do you know any web site about this issue
Tony Edwards
It is wrong to assume that things will work fast just because they are on a LAN.
I guess your bosses are right - the main reason, however, would be that they didn't design the layers to be distributed (e.g. try to make less calls, chunky interfaces etc.)
Arnon
danpanex
The model is both good and bad.
responses:
#1: is this not true in nearly every architecture (at some point you have to rely upon the software to be stable, the same is true if you have say 10 db accessing components on 10 machines ... if there is a software bug it could feasably take down all 10 simultaneously)
2) understanding the loads would be extremely difficult in this case
3) Yes it does make the caching less effective depending on how things are operating ... if its only 17 pages that are regularly viewed then caching will se very little difference.
You mention that the tiers are not seperated at a machine level; is this a point of the design (perhaps a poor design was implemented that makes this very difficult). My guess overall is that you are going to have to spend a long time working on distributing the architecture (and you will probably have alot of political problems doing so unless you can get buy in).
Sam Bent
Hi
Done right - multi-tiered application is more scalable than a single-tier application
However, as I said in the previous post just moving layer and calling them tiers will most likely not work. Take a look at following Ted Neward's presentation on Enterprise Computing Fallacies http://blogs.tedneward.com/content/binary/FallaciesOfEnterpriseComputing.ppt
PS
Also note that Tiers!=Layers (Tiers are physical - Layers are logical)
Arnon
Bill Sullivan
Thanks for both responses. I will try to go deeper.
I think that as in microprocessors you make one transaction longer in pro of scalability, isn't it You make different steps in different layers for accepting lots of access.
What i am trying to say is that in systems that will achieve a great number of access it is better a 3 physical layer or a 2 physical layer
Where do you consider to put the three physical layer overlay Have you develop an architecture like that what is your experience about this issue
Expecting your answers :)
S. Dalby
Sorry for the delay ... must have missed an email alert. As I said before there are pluses and minuses and without knowing further details on the exact situation its really hard to say which is better.
As arnon points out their is a huge cost associated with the network hit, if there is alot of data throughput to the layers this can bring a system to its knees quickly.
The advantages of networking out generally come in horizontal scalability but this can also be achieved through other mechanisms that do not add the same level of complexity.
Anytime you look to marshall data out of your own process space you gain significant overhead which needs to be looked at closely.
It is quite simple ... lets say you have a really fast network, I will give the network trip 1 ms. You also have to in some way serialize/deserialize the message over the network whcih can add significant overhead. This compared to making an in-process call is a huge amount of over (probably 2-3 levels of magnitude, more in real life)