given your load characteristics and deployment situation, i'd recommend using database-backed sessions. if you do that, you're a simple query away from knowing how many active sessions you have at a given time.
you could use the built-in sql server session support. i've seen it work in high volume transactional applications deployed on fairly large server farms, but even then, i still don't really trust it. it's too easy to go overboard and end up roundtripping giant object graphs. this is probably the easiest choice, but i can't say it'd be my first one. i would suggest you keep your own session tracking table by writing a session id and a timestamp to a table when a user logs in and then updating it periodically. in your case, you can probably just do this in your authentication routine, be it ar/nhibernate or a stored procedure or whatever other method you use and in one of the global.asax http lifecycle events for the link tracking[1]. write a sql server job that deletes session records that haven't had activity over whatever period you like and schedule it to run at whatever frequency makes the most sense. [1] if you have any aspirations or expectations that this system might need to scale beyond this load and hardware, don't do it like this. instead of doing these writes directly, look at two options. first, instead of updating your session tracking data with every request, send a message using an ESB like nServiceBus or MassTransit (write your own if you absolutely must, but KISS), and distribute the updates in whatever way you need across multiple servers and even slices of data if you wanted to do bulk inserts because your user load has gotten that large. Distributed messaging using something like an ESB, WCF, or even System.Messaging is the key to straightforward scalability in large web scenarios, in my opinion. the second alternative depends a lot on other infrastructure, but most sites under the kind of load to necessitate something like this would probably have it. instead of logging anything from your application, use a session tracking cookie and parse your logs. this is old-school, but proven to work and low-impact. a more recent twist (to my knowledge at least) on this idea is to use something like an F5, which you can program to write log messages as it sees session cookies going across the wire. a third variation on this is to take advantage of data from your analytics package. if you run something in house, you're in luck, just start tracking session cookies and you've got your data. if you're using something like google analytics, omniture, revenue science, etc., you're not going to be as fortunate. our site (low millions of uniques on an average day) uses this data from our provider by processing reports they FTP us, but they don't transfer the data often enough to use for live session tracking. On Thu, Sep 25, 2008 at 6:31 PM, roundcrisis <[EMAIL PROTECTED]> wrote: > > one a single server > about a 100 concurrent users > > i tinks maybe something like seeing ip, session duration, last click > time, last clcik relative path, if the user is logged in then username > > > On Sep 25, 1:15 pm, "Ayende Rahien" <[EMAIL PROTECTED]> wrote: >> Not enough details to answer. >> On a single server? In a web farm? >> What is the expected user load? >> >> >> >> On Thu, Sep 25, 2008 at 3:12 PM, roundcrisis <[EMAIL PROTECTED]> wrote: >> >> > hi there >> >> > i want o know at any given time ( in a view) whos online, i was >> > thinking of doing this using the session >> > has anyone done this before and do you have any recoomendations? >> > Cheers >> >> > Andrea- Hide quoted text - >> >> - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en -~----------~----~----~----~------~----~------~--~---
