Thought you'd all be interested to know we're up and running, mostly bug free and stable, able to handling nearly 500k visits/hour with 3-10 web servers (Im not sure how many are still online :P), 1 static content server for javascript/css/site images, 2 "mirrors" for hosting actual media, and 1 SQL server (relay coming up soon). Our only fallback was SQL not being able to handle so much.
This was a complete recode of our site to use the Django platform. Everything from the news system and wiki to the forums and files hosting. We also have a video section and several other major features in the works :)
We're still having some issues with SQL load. Trying to eliminate a lot of the queries but.. well, to be honest, I'm having issues finding which ones aren't cached :)
On Dec 10, 11:30 pm, "Jeremy Dunck" <jdu...@gmail.com> wrote:
> On 12/10/06, dcra...@gmail.com <dcra...@gmail.com> wrote: > ...
> > bug free and stable, able to handling nearly 500k visits/hour with 3-10 > ... > > This was a complete recode of our site to use the Django platform.Congratulations, and keep pushing on Django's performance. You're > making everyone faster. ;-)
Thought I'd give everyone an update. We're struggling to stop Django from doing some queries in templates/context procs that we're missing, but we've nearly got the SQL load completely stable (although we're still having some random issues).
We also redid the session system to run completely off memcached, as this was the real killer for the database.
The site's now nearly stable and should have a very high traffic period next month so we'll see how things go :)
> On 12/17/06, dcra...@gmail.com <dcra...@gmail.com> wrote:
> > We also redid the session system to run completely off memcached, as > > this was the real killer for the database.I guess volatile session data is OK, or do you write out sessions from > memcached to disk at intervals?
> I'm going to have a similar problem coming up soon and am curious > which route you took.
On 12/18/06, dcra...@gmail.com <dcra...@gmail.com> wrote:
> It's runing purely off memcached. We have at least 6 memcached servers, > maybe a few more, and it just updates memcached when the session > updates.
This didn't really answer whether volatile session data is OK.
Are you aware that running multiple memcached's results in partitioning of value storage to multiple machines (based on a hash of the key) rather than redundant storage of the values?
You obviously know what you're doing-- I'm just pointing it out since it'd be a subtle problem until one of the memcache's goes down. :)