Addressing scalability ,performance in a .net web application

Question

I\'m working on a .net portal which would be having lots of concurrent users. so scalability,performance need to be addressed in the design and architecture. We plan to use load

Answer 1

Is there another approach? Yes - don't distribute your objects. The most scalable approach is to NOT to distribute your objects away from each other. Ask yourself, why do you want to deploy one flavor of code to an "app server" while another flavor of code goes to a "web server"? The communication that goes on between those two layers, if they are distributed, will be much much much much (etc etc) more expensive than a local call.

With today's 64-bit servers, with all of that memory, and the hot CPUs, and with ASP.NET's superior memory management, why not put your business logic and DAL on the same physical machine as the ASPX files? Why not?

If you need to scale, add more servers. Simple.

There are good reasons, of course, to distribute. The most common good reasons have to do with domains of ownership - along several axes: security management, or even budget and control. In other words, to take the latter case, if team is responsible for running the business logic and a separate team is responsible for building and running the web layer -then it may make sense to distribute those two things to allow independence of management. Most of the good reasons for distributing computer code, have their origins in the structures of the human organizations using or developing the code.

There is no good technical reason why a web page should not run on the same CPU, sharing the same CLR VM and memory heap, as the database access layer.

Regardless what you do with distribution, it would be unwise to architect your system with less-than-formal interfaces defining the connections between the layers. If you keep formal interfaces, then it should be no problem for you to measure the perf and efficiency of a distributed approach versus a co-located approach.

Answer 2

Learn to write asynchronously.
Explore the CCR runtime for example.

Each thread that is blocked waiting for IO responses is one less available to your system.

Turn off 'idealised logging' leave the ability to switch it back on via admin console. But logging is often a hidden bottle neck.

CACHE CACHE CACHE!

If it was expensive to get the data the first time, don't pay for it the second!

Avoid ASP.net's Session State - This can seriously bloat and lead to a large slow down in page responsiveness.

Modify the http headers to specify short browser caching (5sec - 20sec) (Depends on the nature of the content)

Utilise GZIP while you are at it!

AND USE LOTS OF RAM

Answer 3

Here are my tips

1)Move all your static files - images , css, js to a load balancer like nginx. This will greatly reduce the load on IIS server and it will have enough free resources to serve the main request.

2)Think about caching and avoiding database access altogether.

3)Try to implement REST principles are far as possible.

4)Keep session state to a bare minimum - if possible avoid it altogether.

Answer 4

Do you really need an app server? Just how big are you talking exactly? For example Stackoverflow.com has ~50k uniques a day and doesn't have an app server so I assume you are talking much bigger than that? Most performance bottle necks come down to database issues so I would concentrate on that.

Answer 5

I suggest you take a look at the Patterns and Practices groups guidelines for performance, more specifically Chapter 6 - Improving ASP.NET Performance 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&P guideline has the following notes:

Avoid Unnecessary Process Hops

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.

Understand the Performance Implications of a Remote Middle Tier

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:

• You want to share your business logic between your Internet-facing Web applications and other internal enterprise applications.
• Your scale-out and fault tolerance requirements dictate the use of a middle tier cluster or of load-balanced servers.
• Your corporate security policy mandates that you cannot put business logic on your Web servers.

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.

Clemens Vasters (Technical Lead for the Microsoft .NET Service Bus) talks about WCF vs. Remoting in this answer on MSDN forums.

Answer 6

There are some good performance and scalability points in these articles from Omar Al Zabir.
10 ASP.NET Performance and Scalability Secrets
and
99.99% available ASP.NET and SQL Server SaaS Production Architecture
(also check out his book Building a Web 2.0 Portal with ASP.NET 3.5)