I''ve found a few refs to a bit of code to cleanup stale sessions. In my ignorance, I''m not sure what the best practice is for invoking this process. Some talk about a cron job, others say to call it from a frequently invoked action (e.g. login). This article mentions both: http://www.mindsifter.com/2007/1/26/clearing-of-session-data One comment is that the cron job will cause a load of rails each time which could load things too much. Another is that the calling from the login type of action could also cause problems if you''re handling lots of concurrent requests. What do those of you with experience on fairly active sites say? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
adding to this question...
the bit of code I see everywhere to clear stale sessions is some
variant of this:
class SessionCleanup
def self.cleanup
CGI::Session::ActiveRecordStore::Session.destroy_all(
[''updated_at < ?'',
$session_cleanup_interval_in_mins.minutes.ago]
)
end
end
nopte that it calls the detroy_all method...
http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M001384 says
about destroy_all:
"Destroys the records matching conditions by instantiating each record
and calling the destroy method. This means at least 2*N database
queries to destroy N records, so avoid destroy_all if you are deleting
many records. If you want to simply delete records without worrying
about dependent associations or callbacks, use the much faster
delete_all method instead."
So, again, a best practice question:
Since I don''t think there are dependent associations that would need
to be destroyed from the session, why not call the delete_all method
instead?
On Jan 26, 12:46 pm, lunaclaire
<szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:> I''ve found a few refs to a bit of code to cleanup stale sessions.
In
> my ignorance, I''m not sure what the best practice is for invoking
this
> process.
>
> Some talk about a cron job, others say to call it from a frequently
> invoked action (e.g. login). This article mentions both:
>
> http://www.mindsifter.com/2007/1/26/clearing-of-session-data
>
> One comment is that the cron job will cause a load of rails each time
> which could load things too much.
>
> Another is that the calling from the login type of action could also
> cause problems if you''re handling lots of concurrent requests.
>
> What do those of you with experience on fairly active sites say?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
Long
2008-Jan-26 21:56 UTC
Re: [Bulk] [Rails] Re: best practice on invoking stale sessions cleanup?
The solution does depend on the particular situation. It is not clear to me what you are trying to achieve. Is it stale sessions from anonymous visits or ones from account logins that forgot to logout? Perhaps both. In the first case, a cron job that runs say once per day will complete in like a second or two. I don''t see a performance issue here. For the second case I refer you to a previous post. http://groups.google.com/group/rubyonrails-talk/browse_thread/thread/3bc6b2028346baff#b43d2a0485cd46e4 I often employ both methods because each addresses a different area. You are correct, #delete_all is more efficient than using #destroy_all. Provided that it is supported in the context of ActiveRecordStore::Session. I have yet to use it so can''t say for sure. -- Long http://FATdrive.tv/wall/trakb/10-Long http://FATdrive.tv/ ----- Original Message ----- From: "lunaclaire" <szagerman-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: "Ruby on Rails: Talk" <rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org> Sent: Saturday, January 26, 2008 4:14 PM Subject: [Bulk] [Rails] Re: best practice on invoking stale sessions cleanup?> > adding to this question... > > the bit of code I see everywhere to clear stale sessions is some > variant of this: > > class SessionCleanup > def self.cleanup > CGI::Session::ActiveRecordStore::Session.destroy_all( > [''updated_at < ?'', > $session_cleanup_interval_in_mins.minutes.ago] > ) > end > end > > nopte that it calls the detroy_all method... > > http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M001384 says > about destroy_all: > > "Destroys the records matching conditions by instantiating each record > and calling the destroy method. This means at least 2*N database > queries to destroy N records, so avoid destroy_all if you are deleting > many records. If you want to simply delete records without worrying > about dependent associations or callbacks, use the much faster > delete_all method instead." > > So, again, a best practice question: > > Since I don''t think there are dependent associations that would need > to be destroyed from the session, why not call the delete_all method > instead? > > On Jan 26, 12:46 pm, lunaclaire <szager...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > I''ve found a few refs to a bit of code to cleanup stale sessions. In > > my ignorance, I''m not sure what the best practice is for invoking this > > process. > > > > Some talk about a cron job, others say to call it from a frequently > > invoked action (e.g. login). This article mentions both: > > > > http://www.mindsifter.com/2007/1/26/clearing-of-session-data > > > > One comment is that the cron job will cause a load of rails each time > > which could load things too much. > > > > Another is that the calling from the login type of action could also > > cause problems if you''re handling lots of concurrent requests. > > > > What do those of you with experience on fairly active sites say? >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Jan 26, 2008, at 12:46 PM, lunaclaire wrote:> > I''ve found a few refs to a bit of code to cleanup stale sessions. In > my ignorance, I''m not sure what the best practice is for invoking this > process. > > Some talk about a cron job, others say to call it from a frequently > invoked action (e.g. login). This article mentions both: > > http://www.mindsifter.com/2007/1/26/clearing-of-session-data > > One comment is that the cron job will cause a load of rails each time > which could load things too much. > > Another is that the calling from the login type of action could also > cause problems if you''re handling lots of concurrent requests. > > What do those of you with experience on fairly active sites say?If you''re using rails 2.0, and the cookie-based session store, you don''t have to clear out stale sessions. If you are running an earlier version with AR store, you can run a cron job that just runs a mysql command to delete records older than a specified age. No reason to get Rails involved. If you''re really worried about performance, you can nice the command. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Thanks for the replies and sorry for my delay in responding (other matters arose). I am still on rails 1.2.5, so I cant take advantage of 2.0 goodies yet. I like the idea of going directly to the the DB with SQL rather than invoking rails from a cron job. For the moment I am using the code I posted above and calling it from a freq invoked action... works well for now, but I''ll change in anticipation of heavier traffic down the road. On Jan 26, 6:25 pm, "s.ross" <cwdi...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Jan 26, 2008, at 12:46 PM, lunaclaire wrote: > > > > > > > I''ve found a few refs to a bit of code to cleanup stale sessions. In > > my ignorance, I''m not sure what the best practice is for invoking this > > process. > > > Some talk about a cron job, others say to call it from a frequently > > invoked action (e.g. login). This article mentions both: > > >http://www.mindsifter.com/2007/1/26/clearing-of-session-data > > > One comment is that the cron job will cause a load of rails each time > > which could load things too much. > > > Another is that the calling from the login type of action could also > > cause problems if you''re handling lots of concurrent requests. > > > What do those of you with experience on fairly active sites say? > > If you''re using rails 2.0, and the cookie-based session store, you > don''t have to clear out stale sessions. If you are running an earlier > version with AR store, you can run a cron job that just runs a mysql > command to delete records older than a specified age. No reason to get > Rails involved. If you''re really worried about performance, you can > nice the command.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---