Yeah, the db appears to be a bit of a bottleneck as we have to jump through some hoops to get this stuff connected.
Just for fun, I changed the environment to active record sessions, and it dropped from 200ish to ~25. I switched it back, got 200, tried AR again and got the 20s again. So I don't know think I'll be trying database solutions. I'll try and rip apart the code to see how many AR objects I was storing in the session (just 1 or 2 I think) and see about switching that out so I can use memcache. Alexey Verkhovsky wrote: > On Nov 26, 2007 3:05 PM, Bob Br <[EMAIL PROTECTED]> > wrote: >> Otherwise what would you suggest for sessions? > Go with database as a well-rounded default. Switch to memcached if > database becomes the bottleneck. > >> but read on the forum that it won't store activerecord info, and I am >> currently putting some AR stuff in there. > Not sure if I read it right, but if the above means "serialized model > instances in the session", you shouldn't do that. Sessions should hold > IDs. > >> connected to a MS SQL database using the ODBC connection. > Duh... not that SQLServer is a bad product... but Rails community > basically doesn't care too much about it. I wonder if you have to > solve some crappy little problems because of that. Definitely was my > experience with the Rails+SQLServer combo a year ago, and Rails+Oracle > just recently. > > -- > Alexey Verkhovsky > CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com] > RubyWorks [http://rubyworks.thoughtworks.com] -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Deploying Rails" group. To post to this group, send email to rubyonrails-deployment@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-deployment?hl=en -~----------~----~----~----~------~----~------~--~---
