News for hackers. Stuff that matters.

A comment on Ask HN: What is your preferred Python stack for high traffic webservices?. Parent comment

Re:Ask HN: What is your preferred Python stack for high traf... by antimora on Monday August 22, 2011 @12:09AM (#2911259)
Primarily I wanted it to be really fast, be able to invalidate session, and be available on any node via active replication. If I used Beaker, I had to use memcached which is not replicated (by default setup), and each validation would have required 2 round trips to memchached (validation, update stamp).

It's easier to write my own with ZeroMQ and I can build with custom logic at demon level.

[ Parent | on HN ]
Re:Ask HN: What is your preferred Python stack for high traf... by shazow on Monday August 22, 2011 @02:10AM (#2911527)
You don't have to use memcached, the beaker extensions let you use whichever backend storage mechanism you want. Redis Cluster can be replicated and would work fine for this, for example.

I don't have a good grasp of what you're trying to achieve and why, but my overengineering alarms are going off.

[ Parent | on HN ]
Re:Ask HN: What is your preferred Python stack for high traf... by antimora on Monday August 22, 2011 @02:27AM (#2911573)
Thanks for the suggestion. I haven't considered Redis Cluster, but I definitely will.
[ Parent | on HN ]
Re:Ask HN: What is your preferred Python stack for high traf... by espeed on Monday August 22, 2011 @01:31AM (#2911436)
Awhile back I looked into Mongo for sessions, but it isn't really designed to do this. Sessions are temporal, and AFAIK Mongo doesn't have a built in mechanism for expiring them, plus session data is usually small -- there are other datastores better suited for this type of data.
[ Parent | on HN ]
Re:Ask HN: What is your preferred Python stack for high traf... by antimora on Monday August 22, 2011 @02:10AM (#2911525)
Primarily sessions will live in RAM. And I was going to use MongoDB to persist sessions just in case the daemon dies or session is not found in RAM as a fallback. The reason for using MongoDB is because it's my primary database.

But your concern about growing table of sessions is valid, which I will handle by periodically archiving the old sessions so that index sizes remain small.

[ Parent | on HN ]