Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I suggest you take a look at the Patterns and Practices groups guidelines for performance, more specifically <a href="http://msdn.microsoft.com/en-us/library/ms998549.aspx" rel="nofollow noreferrer" title="Chapter 6 - Improving ASP.NET Performance">Chapter 6 - Improving ASP.NET Performance</a> of the guideline. I agree with Cheeso that you should seriously consider NOT physically splitting your application layer and UI layer if you can. The P&amp;P guideline has the following notes:</p> <blockquote> <p><strong>Avoid Unnecessary Process Hops</strong></p> <p>Although process hops are not as expensive as machine hops, you should avoid process hops where possible. Process hops cause added overhead because they require interprocess communication (IPC) and marshaling. For example, if your solution uses Enterprise Services, use library applications where possible, unless you need to put your Enterprise Services application on a remote middle tier.</p> <p><strong>Understand the Performance Implications of a Remote Middle Tier</strong></p> <p>If possible, avoid the overhead of interprocess and intercomputer communication. Unless your business requirements dictate the use of a remote middle tier, keep your presentation, business, and data access logic on the Web server. Deploy your business and data access assemblies to the Bin directory of your application. However, you might require a remote middle tier for any of the following reasons:</p> <ul> <li>You want to share your business logic between your Internet-facing Web applications and other internal enterprise applications.</li> <li>Your scale-out and fault tolerance requirements dictate the use of a middle tier cluster or of load-balanced servers.</li> <li>Your corporate security policy mandates that you cannot put business logic on your Web servers.</li> </ul> </blockquote> <p>If you absolutely have to split the application logic up anyways, you could use WCF as a transport mechanism. I'm not sure how it stacks up against remoting when it comes to performance. However, I seem to remember that this is the guideline Microsoft is pushing.</p> <p>Clemens Vasters (Technical Lead for the Microsoft .NET Service Bus) talks about WCF vs. Remoting in <a href="http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/5219ca92-df97-451d-a44c-cfa4a88c10ae/" rel="nofollow noreferrer" title="Choosing between remoting and WCF">this answer</a> on MSDN forums.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload