I said "instead of logging anything from your application, use a session tracking cookie and parse your logs" but i meant, "use a session tracker id in your urls"
On Thu, Sep 25, 2008 at 9:16 PM, Shawn Hinsey <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
