Curse launches with Django platform

[dcr...@gmail.com]

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.

http://www.curse-gaming.com/ - if you get a white page its because it
can't hit the SQL server :)

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 :)

[Jeremy Dunck]

On 12/10/06, dcr...@gmail.com <dcr...@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. ;-)

[dcr...@gmail.com]

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. ;-)

[João Cruz Morais]

are you using some sort of cache server such as memcache?

[dcr...@gmail.com]

Yes we use memcached

[dcr...@gmail.com]

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 :)

[Jeremy Dunck]

On 12/17/06, dcr...@gmail.com <dcr...@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.

[dcr...@gmail.com]

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.

On Dec 18, 4:42 am, "Jeremy Dunck" <jdu...@gmail.com> wrote:

> 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

[Jeremy Dunck]

(Off-list)

On 12/18/06, dcr...@gmail.com <dcr...@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. :)

[Jeremy Dunck]

On 12/18/06, Jeremy Dunck <jdu...@gmail.com> wrote:
> (Off-list)

Well, it was meant to be. :-/

[Osso]

The only consequences of losing a session for us is the user getting
delogged. So it is not a big deal.

We have set it up, so that it can save the session data in the db as
backup for when we'll need the system to be more reliable.