1

(Apologies for cross-posting with SO. I wasn't sure where it was more appropriate.)

I'm working on a PHP web app deployed to Amazon Web Services. We have load balancers in front of auto-scaled application servers.

The problem we're facing at the moment is handling sessions. While sticky sessions would be a reasonable solution, we'd like to persist sessions for quite a long time (weeks ideally). This is likely to impair the performance of the load balancer over time. Also, using auto-scaling will mean that, from time to time, we'll remove a server and thus lose all of the active sessions on it. Of course, we could just use a common database to store sessions, but I'm a bit concerned about performance if every request requires another round-trip to the DB.

I'd be grateful if you could suggest any solutions that have worked for you, or any ideas that we could try.

Thanks in advance for your help, Ross

Ross McFarlane
  • 191
  • 4

3 Answers3

4

PHP store it's session in plain files. Have you tried storing them on a common storage?

Similiar question: Share PHP sessions in cloud file system

Here is an article about this specific issue and different approaches: http://kevin.vanzonneveld.net/techblog/article/enhance_php_session_management/

Community
  • 1
jishi
  • 868
  • 2
  • 11
  • 25
1

IME, there's little overhead between using file based sessions and database sessions (last time I looked at this in some detail I used master/master replication on 3 mysql nodes) - but the latter more often entails an additional network trip compared to the former (accessing a local mysql instance the difference wan't measurable compared with a local-only filesystem). It's also a lot simpler to scale the db based storage to shared repositories, and since it's a simple key/value methodology, it's straightforward to implement on nosql dbs - which scale even more easily than relational databases.

symcbean
  • 21,009
  • 1
  • 31
  • 52
  • Using an in-memory table for sessions would probably speed up things a lot as well. – jishi Feb 23 '11 at 11:19
  • @jishi - not really - if you tried it you would see this for yourself. Also this is a very bad idea for a cloud based system. – symcbean Feb 23 '11 at 12:33
0

It's already mentioned in the articles linked to by others, but it bears repeating separately: Memcache is a very useful option here. It is blazingly fast, scales to multiple Memcache servers/instances easily and very easy to implement without a lot of overhead or load on the database. I've succesfully implemented this with minimal effort on a site with millions of hits per day and it gave a lot more room for growth on the existing hardware.

Doing it that way also allows the use of Memcache's own aging policy, rather than having PHP's session garbage collector run.

Steven Don
  • 196
  • 1
  • 3
  • Thanks Steve. The reason we're not looking at memcache (at least not on its own) is that if we shut down a server with sessions in memcache, we'll lose its sessions. Shutting down servers is going to be quite common in our auto-scaling environment, so we need some sort of fast persistent storage for sessions. – Ross McFarlane Feb 24 '11 at 11:15