Suggested split of logical tiers over two physical servers?

bluemoo posted on Saturday, February 24, 2007

I've been reading C# 2005 Business Objects, and seem to be having trouble wrapping my mind around the discussion of logical and physical tiers. However, I'm part of a team that develops a web application using ASP.NET and CSLA, and I'm concerned that the way we're using CSLA in a way that reduces performance. I'm sure that the following problem description will reveal my lack of understanding, but I'm hoping that someone here can give me some advice.

Our production environment has a web server, running IIS (thus ASP.NET), and a database server, running SQL Server 2005. We don't use the remoting features of CSLA, so both the business layer and data access layers run on the web server. As far as I can tell, the discussion in chapter one of the Business Objects book says that we should try to put the data access (the DataPortal_* functions) as close to the database as possible, and the business logic as close to the client as possible. Have we configured our environment incorrectly? Should the DataPortal be on the database server?

Thanks for humoring me.

Justin replied on Sunday, February 25, 2007

From my experiece your currently configuration is the best way to go. The TDS protocol used by SQL is very performant and a better choice than remoting.

Although this can depend greatly on how your CSLA objects access the database. If they are very chatty doing multiple dynamic sql requests to bring data into the object to apply BL to it instead of say juditiously moving some of that BL to a stored procedure that is very close to the data. You could see some benifits to using remoting and running those CSLA objects on the SQL server using shared memory instead of TCPIP for actually communicating with SQL but unlikely.

There is another option with SQL 2005 and that is the possiblility of hosting CSLA objects in the SQL runtime, giving you all your CSLA BL but putting in proc with your data store instead of writing TSQL code. I personally havent tried this but definetly want to do some testing.

Justin

ajj3085 replied on Monday, February 26, 2007

Your setup should be fine.  There are a couple of setups you could have though; one is to use the Db server as an application server as well, and setup remoting to point to IIS on the db server.  There's no performance reason to do that though as your still sending data over the wire, possibly more than if your web server talked to the db direction.

The other is to have a new server as your application server.  That would lower peformance though, because now two hops are required to get to the db.  That solution offers more security and scalability though. 

I think your current setup is fine though, and it doesn't sound like either of the alternatives are needed yet.

bluemoo replied on Monday, February 26, 2007

I'm going to stick with the current configuration; thanks both of you for your help.

RockfordLhotka replied on Monday, February 26, 2007

The fewer tiers you can use the better your performance will be.

More tiers are used typically to get either scalabilty or security.

In the web world, your web server IS your app server, so it is very hard to get more scalability by adding a layer of app servers behind your web servers. It is not impossible, but in most situations you simply lose performance for no gain.

However, in the web and Windows worlds both, there can be security gains by having an app server, because the client (or web server in your case) doesn't need the credentials for the database. It is a layer of indirection that helps hide secrets (the keys to the database).

If that security is of value to you though, you'll lose some performance to get it, because of that extra network hop. So it should be a very concious decision one way or the other.

But all this is why I spent the time to discuss the difference between layers and tiers. You can't do tiers (in a meaningful way) without first doing layers. You can't even have a quality discussion about which tiers should run which layers if you don't first have layers. AFTER you have layers, then you can discuss the various trade-offs relating to tiers - like this conversation right now.

Personally, for web apps, I recommend using a 2-tier model (the browser doesn't count) when possible, and only falling back to a 3-tier model when the security needs outweight performance requirements.

For Windows apps I think the decision is slightly harder. The perf hit is there for having an app server, but the scalability and security benefits are much easier to see, and they are complimentary. In other words, you get both scalabilty and security at once with an app server, and so it is easier to justify in that environment. But even so, it is not a slam-dunk, because there's still the perf hit, and there's still the increase in complexity and possible points of failure.