3

We are using Sitecore 8.1 to develop an Enterprise-level Website, this site receives around 1/2 million users.

We have a user dashboard and other details that the visitor can see after login, and they can browse protected pages and edit their details like any normal account.

Is it a good idea to keep user details in Session (InProc) and check a session value if they want to access protected pages or we can use Sitecore's Virtual User concept?

Which approach should we take in terms of scalability, security and performance?

Improve this question
2
  • 2
    if you are doing any kind of load balancing, then InProc session is not the way to go - you will need some kind of shared session state.
    – Richard Seal ♦
    Commented Feb 6, 2017 at 16:08
  • if your solution is load balanced and your load balancer is not sticky then you need to consider sticky sessions too, let me know if you need any more information on how to enable that in sitecore
    – Mrunal Daftari
    Commented Feb 6, 2017 at 18:11

2 Answers 2

Reset to default
3

We have a similar requirement (1/2 million named users) and went the method of sitecore virtual users, and then assigning a specific sitecore role when they are authenticated. You can then authorise which sitecore items (pages) the role has access to.

I'd also suggest you look into implementing your own membership provider, however it does add complexity.

Improve this answer
2
  • Hello Gibbocool, We also have the similar kind of requirement and implemented using virtual user. Is there any performance issue you had faced. currently we have 2 CD servers and 1 CM server
    – PVM
    Commented Jan 26, 2018 at 3:19
  • No issues but I suppose it also depends on volume of concurrent users, which ours is fairly low. We did have an issue with sitecore analytics in that on user logout we were clearing the session with Session.Clear(); Don't do that ;)
    – Mark Gibbons
    Commented Jan 28, 2018 at 22:31
2

You should definitely not be using InProc session, as @RichardSeal mentioned. Further, you need to clarify whether the site has 500k named users, or just takes 500k visitors per month.

Assuming the former (500k named users), you may want to look at virtual users because ASP.NET's authorisation and profile subsystems may not gracefully handle a volume this large. You could customise an approach to address that, however.

Either way, you are going to need session-state to keep your user logged in from one page load to the next or invent a token-based system that you can round-trip. Use of session-state is one of the biggest causes of performance and scalability issues, but the alternative is non-trivial.

If you get 500k visitors to the site, but only have a few thousand named users, you should have no trouble with Sitecore's out of the box solution.

Improve this answer
3
  • just to clear the doubts their are 500k named users but yes concurrently the max number of logged in users max out at 500. Is it still a good choice of implementaion?
    – Shailesh
    Commented Feb 7, 2017 at 6:38
  • 500 concurrent, logged in users is still a lot. Don't forget that session timeouts are generally 20 minutes, so if a normal user session is 5 minutes you will have several thousand sessions in memory at any time - this could be gigs of memory. You definitely need proper out-of-process session handling and several Sitecore servers for this; maybe 2 quad-cpu or 3 dual-cpu boxes with 8-16GB RAM each. 1/2
    – Richard Hauer
    Commented Feb 8, 2017 at 10:45
  • I think the decision about virtual users is still about how much personalisation and reporting info you need to handle. You will definitely need a custom authentication and authorisation system, and it will have to be very high performance - a MongoDB collection with appropriate indexing in a good start; session backed by Redis with careful management of the session data will help too
    – Richard Hauer
    Commented Feb 8, 2017 at 10:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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