Design guidelines to support about 400+ concurrent users in a web application

Question

I am at the beginning of an average asp.net C # project and demanding application performance to support about 400+ concurrent users.

What things do I need to keep in mind when developing an application to meet such standards of performance and availability? A page should be submitted in less than 5 seconds. I plan to have an application and a database on separate physical machines. From the point of view of coding and application application: -

• If I have a database layer that is displayed at the application level through WCF, will this interfere with performance? Should I use direct tcp instead?
• Will it matter if I use the Entity framework or some other ORM or corporate library data block?
• Should I write exceptions from a database or text file?
• How to check during development if the built code will eventually meet these performance standards? Or is this even the point I need to worry about at the development stage?
• Do I need to put the database connection code and other classes containing search data, which rarely change for the life of the application, in static classes, so it is available throughout the life of the application?
• What caching policy should I apply?
• What free tools can I use to measure and test performance? I know the red gate performance measurement tools, but I have a high license price, so free tools are what I would prefer.

I apologize if this question is too open. Any tips or thoughts on how I should act?

Thank you for your time.

Answer 1

An important consideration when developing a scalable application is its absence. No sessions. Another important consideration is to cache everything you can to reduce database queries. And this cache should be distributed to other machines that are specifically designed to store it. Then all you have to do is drop the additional server when the application starts to run slowly due to increased user load.

As for your questions about WCF, you can use WCF, this will not be a bottleneck for your application. It will definitely add an extra layer that slows things down a bit, but if you want to open a reusable layer that can scale independently of your own WCF, that’s fine.

ORMs can really slow down the performance of your application. This is because you have less control over the generated SQL queries and therefore are more difficult to configure. This does not mean that you should not use ORM. You just need to be careful that it spits and tunes SQL using the database administrator. There are also light ORMs such as dapper , PetaPoco, and Massive that you can consider.

As for static classes, they will not improve performance far superior to instance classes. Creating an instance of the class on the CLR is a fairly quick operation, as Iyende explains . Static classes will introduce a hard link between your data access level and your consumer level. Therefore, you can forget about static classes at the moment.

I would recommend ELMAH for error reporting .

There are quite a few tools for benchmarking; Apanche Bench is easy to use.

Answer 2

There is always a trade-off between productivity, maintainability and developer productivity; you can really really make this compromise reasonable if you can measure it. Performance is measured by how long it takes to do something; maintainability is harder to measure, but fortunately, performance is simple enough to quantify. In general, I would say to optimize productivity and serviceability first, and only optimize performance if you have a measurable problem.

In order to work in this way, you must have performance targets and a way to regularly evaluate the solution for these goals - it is very difficult to retool the performance in the project. However, optimizing performance without proven need leads to obscure, hard-to-debug software solutions.

First, you need to turn the target audience into a number that you can measure; for web applications, which are usually "dynamic page requests per second." 400 concurrent users, probably not all request pages at the same time - they usually spend some time browsing the page, filling out forms, etc. AJAX-driven sites, on the other hand, request much more dynamic pages.

To use Excel or something to work from peak concurrent users to dynamic page roles per second depending on latency, interaction requests and creation in the buffer - I usually reassign by 50%.

For instance:

400 concurrent users with a session length of 5 interactions and 2 dynamic pages for each interaction 400 * 5 * 2 = 4000 page requests.

With a 30 second timeout, these requests will be distributed within 30 * 5 = 150 seconds.

Therefore, your average page requests / seconds are 4000/150 = 27 requests / second.

With a 50% buffer, you should be able to maintain a peak of approximately 40 requests per second.

This is not trivial, but by no means exceptional.

Then set up a performance testing environment, the characteristics of which you fully understand and can replicate, and can display the production environment. I usually do not recommend re-creating production at this point. Instead, reduce the number of pages / second page benchmark according to the performance testing environment (for example, if you have 4 servers in production and only 2 in the performance testing environment, halve it).

Once you start developing, regularly (at least once a week, ideally every day) deploy your unfinished work in this test environment. Use a test load generator (Apache Benchmark or Apache JMeter work for me), download load tests that simulate typical user rides (but no latency), and run them against your performance testing environment. Measure success by clicking on the Generation / Second landing page. If you aren’t in the benchmark, find out why (Redgate ANTS profiler is your friend!).

As you approach the end of the project, try to get a test environment that is closer to the production system in terms of infrastructure. Expand your work and repeat performance tests, increasing the load to reflect the “real” pages / second requirement. At this point, you should have a good idea of ​​the characteristics of the application, so you really confirm your assumptions. It is usually much more difficult and expensive to get such a “production" environment, and it is usually much more difficult to make changes to the software, so you should use this only for verification, and not for the usual work to increase productivity.