On 20 Sep 2009, at 18:35, James Englert wrote: > I feel like I'm missing a major point here. Assuming the table is > correctly range partitioned and indexed, most databases should be > able to handle relatively large table sizes. I agree that is a best > practice to archive old, unused data, but that can likely be done on > a monthly basis, or less often, depending on traffic. Why would you > need to consider a solution that "will ramp up proportionally with > traffic"?
The original poster was asking for the correct way to clean the sessions table. Although there is no clear cut answer to that one, I personally feel random number generation is by no means the correct way to go. Yes, the database should be able to look up sessions very quickly, but as you pointed out, depending on traffic, it will eventually drain needless resources as the number of records increase, both in terms of server cycles and storage. Now, until cookie-based storage became available, we used the database for session storage and used quite a few techniques over the years we've been developing Rails apps. As the number of applications increased, we started handling it differently. In rough lines, we used: - First couple of applications: before_filter triggered by authentication (or some other action that clearly had to do with sessions) - Cron tab that invokes script/runner during low traffic times (the problem here was that for each of the applications, a whole Rails instance was started and that consumed quite a bit of memory as the number of apps increased on the VPS we then had) - Cron tab that invoked the mysql command line and just went through all of the databases deleting sessions in one session The last solution was really quick, used very little resources and worked fine during the time we actually needed it. It was a little bash script, nothing special, along the lines of: mysql -h localhost -u[someuser-with-necessary-privileges] < sql_commands_file where sql_commands_file just had a series of commands to clean the sessions: USE databasename1 DELETE FROM sessions WHERE NOW() - updated_at > 3600 USE databasename2 DELETE FROM sessions WHERE NOW() - updated_at > 3600 USE databasename3 DELETE FROM sessions WHERE NOW() - updated_at > 3600 I think we cleaned it up a bit by just generating the whole sql commands sequence in bash using loop script, but you get the picture. Best regards Peter De Berdt --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
