Sorry, I don’t have any experience using this. The authentication I used was faked by setting the cookie header to a known value. In your case, httperf is handling sessions by itself – receiving a cookie and sending it on subsequent requests.

And if your indexes are already good, cache the objects for which queries are the most expensive. You could also check your my.cnf values and try to tune it, but 256Mb of RAM is a bit short…

Nice article though !

Thanks for the suggestion to disable keep-alive for the dynamic content. I tried it, but it seems to have made no difference.

The Lighttpd docs refer to disabling keep-alive as “the last resort”. Reducing the requests and idle time from the defaults didn’t seem to make a difference either.

@jeo

We’re old SQL hounds, so we know all about joins and unions. :)

A wall has multiple items. Each item is sent by a user and can have several pieces of media (e.g. photos).

The initial/naive approach was one query (through normal Django ORM) for the wall then in the template something like:

{% for item in wall.items.all %}
…
{% with item.sender as sender %}
{{ sender.name }} etc…
{% endwith %}
…
{% for media in item.media.all %}
…
{% endfor %}
…
{% endfor %}

I would say this is pretty standard — it’s the easy, natural way to work with the ORM. Of course, it means we are doing one query for the items and then two queries for each item, which is bad news. In some cases, select_related() will help, but not in this case as we had some nullable foreign keys.

This can be done far more efficiently, as you say, by joining the tables, or doing a couple of queries and stitching the data together in Python. That’s what we did during optimisation.

@Vance

The point of newforms and ORM and all this stuff is to make it easier/quicker to develop and maintain. There’s obviously a big performance trade-off. I totally agree with you that Django makes it easy to drop down a level when you want to trade ease for performance.

@Doug

Thanks for sharing some numbers for the PyCon website. What’s the hardware spec of the server?

Hundreds of req/s is certainly more appealing. We are using values() now to avoid lots of queries, but no caching yet.

When you benchmarked at 800 req/s, did your test make requests as multiple users? It occurs to me that caching could be misleading when testing performance since one user making 800 requests is very different from 800 users making one request each!

I might have a play with mod_wsgi at some point — looks interesting.

I also recommend using mod_wsgi in deamon mode instead of fastcgi, using file based session caching, and memcached.

looking at the site, I see no reason why you should not be able to do 1000 requests per second.

Personally I’ve taken to using a hybrid approach, use some of the framework and hand code alot. For instance lose newforms entirely it’s an amazing waste of memory and cpu cycles ( still can’t figure out why it exists ), don’t use Models on any queries that happen alot, if you do use Models use ’select_all’, QuerySet is the devil when it comes to speed.

One of the most beautiful things about Django is that you can subvert Django when you need to and go straight to the underlying tools.

Are you retrieving items then doing a separate query for the details of each one? Why aren’t you just doing a join in the database?

Different types of items, stored in different tables? Do a union query with left joins. Or do a query for each type of item if you must, and sort them out in your web code.