I was at the Magenic Code Mastery event in Atlanta this past weekend, and during the Q&A time I asked about using 2-tier or 3-tier deployment for a CSLA app that runs with about 400 concurrent users, in a Windows/AD environment, with most users on the LAN. Rocky mentioned that in this particular scenario, 2-tier would probably be best because the DB servers these days are quite efficient and powerful enough to service this load (unlike 10+ years ago). He also mentioned that for our 100 or so users who are on the WAN it would be beneficial to deploy as 3-tier, since they would be hitting the app server that sits next to the database server.
After I left, I realized I didn't quite understand how this translates into better performance and wanted to ask (I realize this isn't strictly related to CSLA):
Since CSLA objects are mobile, and those objects are serialized and sent over the wire to an app server so that they can be re-created and then interact with the database, is the benefit in 3-tier on a WAN due to those objects being smaller in size than the amount of data that would be sent to the DB server directly when running in 2-tier mode? Or is there something else that accounts for the benefit in running a 3-tier deployment when users are on the WAN?
In a 2 tier the client talks directly to the database.
Imagine saving 100 rows of data on a WAN in a 2 tier vs 3 tier model:
2-tier: make 100 sql calls to the database using a database connection and handles transaction(s) over a potentially slow line or
3: tier: make 1 call (Save) to the server and the server makes 100 sql calls and handles transaction(s) on the LAN to the database.
Plus Sql connections use custom ports that are typically not open/available to the outside world whereas http/https typically is.
You would not even need to have the database client software installed on the clients.
So from a communications perspective (ports and protocols), to avoid "chatty" direct sql connection and simpler software distribution are all advantages in a 3-tier scenario.
Copyright (c) Marimer LLC