I presented at the MelbDjango user group on 11 July 2013, here’s the slides:

Notes =====

Some quick scribblings re: the content of my talk, and the feedback from the Djangonauts present.

Performance Testing

I’m talking about Performance Testing, not particularly about Performance Improvement, although I’ll touch on a few common traps later. Specifically, I’m splitting testing up into:

Test Platform

This is really just a plug for Amazon AWS :-)

Synthetic Test Data

Empty databases go fast! You need to work with the business people, or your own business plan, to work out what the requirements of “success” are for your project, and then generate synthetic test data which fits that profile, so that your testing actually has some meaningful results.

Django makes it very easy to generate test data from simple Python code. I like the ‘random’, ‘inflect’ and ‘loremipsum’ modules for this. Generating test data which looks a lot like real data not only makes your testing more relistic, it makes the test data useful for your designers etc as dummy data.

note

Sam Stewart pointed out Factory Boy which I haven’t used but looks like an easy way to set this up.

Simulating Load – Siege

Siege is one of the easier load testing tools to get into.

The important thing here is to make sure your load testing model also matches the business model … Three big things to consider are:

I had collected some data showing this off but it didn’t really fit into the time available, maybe next time!

System Under Load

note

I somehow didn’t end up with a slide for this, but …

Look at where the CPU is going:

Antipatterns – N + 1

Or: how to not torture your SQL layer.

Query Logging

Postgres & MySQL both offer quite good options for logging queries.

note

There’s also lots of middleware options, which I think I forgot to mention.

Other Bottlenecks

Other Stuff