Ask YC:how do you do Sessions on EC2? | Hacker News Reader

Ask YC:how do you do Sessions on EC2?

4 pointsjdavid12 comments

I have been thinking of implementing a replacement session handler for PHP you can see more here.

http://us3.php.net/session_set_save_handler

my custom version would be for ec2 s3 and or simpleDB so that I can do RRDyDNS and have session state stored between server instances for load balancing.

I was wondering what the crowd thought, and how some of you might be tackling the sessions problem on ec2? DB?

View on HN

I'm thinking this might be a 'bad' idea unless you are also hosting the site on EC2. Having significant latency in your session handling will bring your site to a crawl due to IOWAIT on your web servers. Obviously making a request across the net for session data will be slow compared with a request across a local network.

Now, assuming you are also hosting your web servers on EC2, I would recommend using neither S3 or SimpleDB for hosting sessions. S3 is more appropriate for static data, and SimpleDB is still in early Beta (as in, the API is subject to change and you have no SLA).

Session data is largely meant to be ephemeral. Consider using a standard MySQL (or similar) session backend with a circular hash for distribution to different nodes. Unless you are doing a ton of traffic, you can get by with a single machine running the session backend. The MySQL backend scales to a lot of concurrent users.

this is a little more complicated/ costly then i care to implement on a new site. Yes the site is on ec2, but i think i am going to seriously avoid MySQL in aws. if a server crashes your log files are not valid, because the virtual machine hard drive gets disposed. Setting up MySQL on ec2 seems like it should have at least 4 servers running. I will wait till traffic demands it.

That's a cool idea. How fast is simpleDB on EC2? I'd be interesting in contributing.

thats what i would like to know. i am still waiting on access to the beta. are you up with doing an S3 version?

it looks like a cool path would be:

# support s3

# support some cache (memcache/ThruDB)

# support SimpleDB with cache

I'd like to make it as simple as possible, an S3 version sounds like a good start. Send me an email if you get a chance - johnwehr@gmail.com

memcached

That's considered to be a bad idea generally.

http://www.socialtext.net/memcached/index.cgi?sessions

But memcached + s3 as the backing store could work. Or for a low traffic site you might just be able to use s3 directly.

This might be what you mean, but a combination of memcached and a replicated database running on some ec2 boxes should work pretty well. The socialtext link implies that.

I haven't used simpledb yet, but as far as I understand it seems like it could be a good use case for replacing the replicated database piece.

All you need for your backing store is a dumb key/value dictionary. You want S3 for that. Even with replication, running a DBMS on EC2 is a dreadfully foolish idea. A lot of startups are going to immediately go under the moment that EC2 has its first system-wide crash, and I'm going to be laughing at their misery.

Here is the thing. What makes some other solution more immune to a system-wide crash than ec2? When that happens, what is the major difference between that solution and an ec2 based one? If you really want to play it safe and don't trust amazon, then what you want is a disaster recover site which is completely independent. However, wouldn't you also want the same for any isp/hosting solution?

It isn't a question of who you trust. It's a question of what classes of events that your system can withstand. EC2 is not durable. It isn't designed to be.

Reply on news.ycombinator.com