4

I appreciate all help and feedback. Parts bolded are critical parts if this is too verbose. Perhaps it will help to mention I am a green developer. I have found some useful info from related questions posted here and on Stack Overflow but nothing that felt 100%.

Background

Currently at work we are developing a web application with strict constraints set forth by the client. Normally we are a Rails shop, but the client really wanted to work with us. Thus to fit into their architecture we will be using ASP.NET. We are not very experienced with ASP.NET but some of the team including myself have used .NET for desktop applications.

This application is three tiered and includes:

  • Public facing server(s)
  • Web services server(s)
  • Data server(s)

The client is expecting high demand and they may have multiple servers in any one of the tiers. There is a firewall between every tier. From my understanding this is a very common set up.

A core goal is to minimize trips over the wire from the public facing server to the database.

The Problem

How do we handle user authentication without hampering performance on an N-Tier application with potentially many servers at each layer?

What We've Done so Far

We toyed with the idea of using view state but ultimately felt like this would be a poor idea. Of course we are not opposed to re-visiting view state, but feel that view state offers no benefits over cookies and simply makes it harder for a user to have multiple tabs of our application open.

I have been exploring the path of using the default session state with a custom implemented session store. The default session state tends to generate multiple requests going over the wire. Logging in and out this is okay, but when the user is using the app we do not want this. The custom session store helps minimize impact, but not by enough.

Conclusion & Possible Idea

Since trips to the database will be inevitable on almost all requests once inside the application, perhaps giving the user a key on successful login is the best way to go. Then when the user requests a new page, or posts a new page we could send that key with the related SQL transaction for the request and validate the key. I believe this will simplify the code base immensely.

So to re-iterate the problem: How do we handle user authentication without hampering performance on an N-Tier application with potentially many servers at each layer? Does the idea above sound like a solid implementation?

Thanks,
Jonathon

|improve this question
  • I know this is quite old post, but still would like to know How did you achieved resolution for this scenario. It will help me in learning to handle such scenarios. – Krishna.N Dec 5 '13 at 3:36
2

Maybe I'm cynical but I smell a common problem here. They are expecting high demand and so are doing distributed everything from the get go with careful optimization. Before they have a product.

How do they know that they will get all of this traffic?

If they get all of this traffic, how do they know that something simple won't scale?

The right solution is to implement a simple function that behind the scenes does a simple database request, but which later can be switched out for something fancy. And then don't worry about it until there is a proven problem. A decade ago I did something similar, and we didn't hit scaling problems until 100k dynamic pages/hour. And when we hit problems there, it wasn't hitting the login that was the problem!

Yes, I could suggest lots of fancy architectures that scale better. I've built some as well. But until you need to go there, assume that you won't.

|improve this answer
  • 1
    Totally agree. There are lot of optimizations that can be added later, such as pre-active caching, application pool "global" state etc. – Chris Mylonas Nov 17 '13 at 14:31
  • Generally good advice, but there are definitely circumstances where you know you will get high load for a new project, especially if they are a big brand with big marketing budgets, or the application is actually replacing an existing one. So this answer doesn't really answer the question and might be better as a comment. – Ben Feb 19 '18 at 0:01
  • @Ben If you are replacing an existing application, you will need to cooperate with whatever the existing solution is. A "big brand with big marketing budgets" in my experience either wildly overestimates their power, or else through experience has learned an existing type of solution that they will want everyone to use. As for the rest, KISS will probably scale better out of the box than any kind of sophisticated distributed architecture that they might have. – btilly Feb 19 '18 at 16:59
  • @btilly There are numerous situations where you can be sure of traffic though, existing brands do have good ideas of their reach as they've been reaching for years already. Also I have only just noticed this question was from 2013, and I'm trying to figure out how I ended up here! Sorry to dig this up. – Ben Feb 19 '18 at 22:57
  • @Ben My experience is that offline brands have a good idea of their customer base, and are poor at projecting how many of those customers really want to login to their website, or use their custom app. Online brands have a much better idea how many people want to login...and also have a solution for that that they want you to use. In any case a dead simple approach won't be a bottleneck to surprisingly high volume. – btilly Feb 19 '18 at 23:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.