High performance .Net website

2

I'm going to start building a website to buy tickets and the forecast for main page access is 8000 users per minute.

We will use C # .Net and MVC.

The database, project standard, ORM, and frameworks are open and can be chosen.

So far I think of doing a WebApi 2.0 with standard Repository and Micro ORM Dapper, AngularJS and SQL Server database but would like to know some opinions.

What is your suggestion? Would you implement a queuing system or for that amount of users is it not necessary?

Obs. Consider a medium to low potential server.

    
asked by anonymous 30.09.2015 / 04:59

1 answer

3

Consolidating what's in the comments.

Any decision has to undergo stress testing and stress or actual use in production. It's no use supposing things. And you'll have to redo these tests as you add functionality.

In any case, if you do not know what you are doing, you will have problems regardless of the system you create and even the hardware you use.

This system of queues for me is a bit weird. I think it's barbequeing, I doubt what it would take if I knew what it was doing.

The Stack Exchange network you are using now has lots of access and has no problems . They basically use the technology you want to use . Can MongoDB Be Better Than SQL Server Pro Your Case? You know better than I do.

I have my doubts if I should use AngularJS, I think there is a lot of use for fashion, but it would just be my opinion. I even think this will reduce the effort required on the server. But there are other good or bad implications.

Of course at some point the solution is to add hardware. Horizontally or vertically. There's no way. And it's absurdly cheaper than implementing a software solution that's too complex to develop or support.

The biggest mistake I see in this statement is to specify on which hardware to run. The hardware should be scaled according to the need, not be changing the software to meet the hardware limitation, because this is not always possible. Even when it is, the option is the worst possible.

As you need it, you can improve things. But at first I would learn a lot about caching. Do it on several levels. This helps a lot to have scalability and even deal with some types of attacks.

Of course, the design of the application can greatly influence performance. I'm not going to talk about this because there are no details that I can say something suitable, but I see a lot of software having performance problems because they were poorly designed (nor am I talking about poorly written code, which also causes problems). At some point you will have to think about whether you want a feature. There are things that would make this site much better than it is, but it does not allow it because it would greatly increase the cost of processing. They opted for performance over UX (although performance is also an aspect of UX). There are many websites that do this. Facebook and Google live making decisions like this. But remember you're not Facebook.

    
30.09.2015 / 16:56