0

i am on the way to load balance some drupal site, 2 servers running the exact same site, DB running on a different server that both access, and another server where the load balancer will run.

I am following this guide and i was wondering about that sticky session part.. Since i have all the shared static data stored in a NAS accessed by both drupal servers, why not defining in the PHP.ini of both drupal servers the session.save_path to some location on that NAS instead of using sticky sessions? would that work?

what are the pros and cons of that? thanks!

Julien
  • 2,217
  • 2
  • 28
  • 49

2 Answers2

0

Now, when you want to access session on either server, you have to make a network request to the NAS as opposed to maintaining session in memory on either Drupal server. Basically, it's slow.

A faster approach is to remove Session entirely from your application and enjoy the speed benefits as well as administration benefits.

Alternatively, you can go with the sticky sessions, but this makes administration of your server farm more difficult.

Macy Abbey
  • 3,877
  • 1
  • 20
  • 30
  • thanks for the quick reply! removing session entirely? how would that work out? i am not sure if i understand that suggestion.. :) – Julien Jan 30 '11 at 19:23
  • You would need to use other parameter passing methods between components of your application. So page A wants to pass information to page B, you would need to use: query params, post params, cookies, db store or some other method than Session. Alternatively you could do as you have already suggested which is push Session to a data store that is accessible by every webserver. Please do not use Memcached. Pain ensues. – Macy Abbey Jan 30 '11 at 20:36
  • memcached is a perfectly valid solution, as a cache. – Arnaud Le Blanc Jan 31 '11 at 18:47
0

The almost canonical answer to this is memcached. It's the way to store session if you have more than one webfrontend. Once you have it, you can begin exploring it for speed by using it for cache.

chx
  • 11,270
  • 7
  • 55
  • 129
  • This is a really bad idea; memcached is a cache store, and keys can be expired at any time, for many reasons, which could logout your users, and really bother them. Memcached is often used as a cache for sessions, but not as main session storage. Please read [this](http://dormando.livejournal.com/495593.html) by memcached's author. – Arnaud Le Blanc Jan 30 '11 at 19:41
  • I did not want to suggest mongodb :) Downvoting is IMO totally unfounded, despite the warnings of memcached's author everyone is storing their sessions in memcached because of the speed reasons. There can be many more reasons you get logged out (for eg your browser crashed and did not write out the session cookie) and so the tradeoff is not horrible. – chx Jan 30 '11 at 20:40
  • 1
    I'll ++ if you can provide some reference as to who is everyone? – Macy Abbey Jan 30 '11 at 21:13
  • memcached will prematurely expire sessions more often than browsers crash. This _everyone_ caches its sessions in memcached, but also keeps a copy of them in a persistent store, e.g. if (!fetch_from_mem()) { fetch_from_persistent(); } – Arnaud Le Blanc Jan 31 '11 at 18:45
  • I'm not going to weigh in on whether it's the right way, but you guys make it sound like no one stores sessions in memcache,, which is entirely untrue. http://stackoverflow.com/questions/13946033/is-it-recommended-to-store-php-sessions-in-memcache – James Alday Feb 20 '14 at 20:13