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

Improve this question

3 Answers 3

Reset to default
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/

Improve this answer
2
  • Thanks. I'd vote you up, but I don't have enough reputation!
    – Ross McFarlane
    Feb 23, 2011 at 11:30
  • @RossMcFarlane , i did that for you :)
    – BigSack
    Aug 20, 2013 at 4:47
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.

Improve this answer
2
  • Using an in-memory table for sessions would probably speed up things a lot as well.
    – jishi
    Feb 23, 2011 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, 2011 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.

Improve this answer
1
  • 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, 2011 at 11:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .