This is a pre-production deployment of Warehouse, however changes made here WILL affect the production instance of PyPI.
Latest Version Dependencies status unknown Test status unknown Test coverage unknown
Project Description

“Keep detailed records of the performance of your Django code.”

django-perf-rec is like Django’s assertNumQueries on steroids. It lets you track the individual queries and cache operations that occur in your code. Use it in your tests like so:

def test_home(self):
    with django_perf_rec.record():
        self.client.get('/')

It then stores a YAML file alongside the test file that tracks the queries and operations, looking something like:

MyTests.test_home:
- cache|get: home_data.user_id.#
- db: 'SELECT ... FROM myapp_table WHERE (myapp_table.id = #)'
- db: 'SELECT ... FROM myapp_table WHERE (myapp_table.id = #)'

When the test is run again, the new record will be compared with the one in the YAML file. If they are different, an assertion failure will be raised, failing the test. Magic!

The queries and keys are ‘fingerprinted’, replacing information that seems variable with # and . This is done to avoid spurious failures when e.g. primary keys are different, random data is used, new columns are added to tables, etc.

If you check the YAML file in along with your tests, you’ll have unbreakable performance with much better information about any regressions compared to assertNumQueries. If you are fine with the changes from a failing test, just remove the file and rerun the test to regenerate it.

For more information, see our introductory blog post that says a little more about why we made it.

Installation

Use pip:

pip install django-perf-rec

Requirements

Tested with all combinations of:

  • Python: 2.7, 3.5
  • Django: 1.8, 1.9, 1.10

API

record(file_name=None, record_name=None, path=None)

Return a context manager that will be used for a single performance test.

path is the path to a directory or file in which to store the record. If it ends with '/', or is left as None, the filename will be automatically determined by looking at the filename the calling code is in and replacing the .py[c] extension with .perf.yml. If it points to a directory that doesn’t exist, that directory will be created.

record_name is the name of the record inside the performance file to use. If left as None, the code assumes you are inside a Django TestCase and uses magic stack inspection to find that test case, and uses a name based upon the test case name + the test method name + an optional counter if you invoke record() multiple times inside the same test method.

file_name is deprecated in favour of path and will be removed in a future major release. It can be used to point to the filename in which the record should be stored, which path supports too.

Whilst open, the context manager tracks all DB queries on all connections, and all cache operations on all defined caches. It names the connection/cache in the tracked operation it uses, except from for the default one.

When the context manager exits, it will use the list of operations it has gathered. If the file file_name doesn’t exist, or doesn’t contain data for the specific record_name, it will be created and saved and the test will pass with no assertions. However if the record does exist inside the file, the collected record will be compared with the original one, and if different, an AssertionError will be raised. When running on pytest, this will use its fancy assertion rewriting; in other test runners/uses the full diff will be attached to the message.

Example:

import django_perf_rec

from app.models import Author

class AuthorPerformanceTests(TestCase):

    def test_special_method(self):
        with django_perf_rec.record():
            list(Author.objects.special_method())

TestCaseMixin

A mixin class to be added to your custom TestCase subclass so you can use django-perf-rec across your codebase without needing to import it in each individual test file. It adds one method, record_performance(), whose signature is the same as record() above.

Example:

# yplan/test.py
from django.test import TestCase as OrigTestCase
from django_perf_rec import TestCaseMixin

class TestCase(TestCaseMixin, OrigTestCase):
    pass

# app/tests/models/test_author.py
from app.models import Author
from yplan.test import TestCase

class AuthorPerformanceTests(TestCase):

    def test_special_method(self):
        with self.record_performance():
            list(Author.objects.special_method())

Settings

Behaviour can be customized with a dictionary called PERF_REC in your Django settings, for example:

PERF_REC = {
    'MODE': 'once'
}

The possible keys to this dictionary are explained below.

MODE

The MODE setting may be used to change the way django-perf-rec behaves when a performance record does not exist during a test run.

  • 'once' (default) creates missing records silently.
  • 'none' raises AssertionError when a record does not exist. You probably want to use this mode in CI, to ensure new tests fail if their corresponding performance records were not committed.
  • 'all' creates missing records and then raises AssertionError.

History

Pending release

  • New release notes go here

1.1.1 (2016-10-30)

  • Fix django session keys not being fingerprinted.
  • Show diff when records don’t match (when not on pytest).
  • Add new ‘MODE’ setting with three modes. This allows customization of the behaviour for missing performance records. The new 'none' mode is particularly useful for CI servers as it makes tests fail if their corresponding performance records have not been committed.

1.1.0 (2016-10-26)

  • Fix automatic filenames for tests in .pyc files.
  • Add the path argument to record which allows specifying a relative directory or filename to use. This deprecates the file_name argument, which will be removed in a future major release. For more info see the README.

1.0.4 (2016-10-23)

  • Work with sqlparse 0.2.2

1.0.3 (2016-10-07)

  • Stopped setup.py installing tests module.

1.0.2 (2016-09-23)

  • Confirmed Django 1.8 and 1.10 support.

1.0.1 (2016-09-20)

  • Fix install_requires in setup.py.

1.0.0 (2016-09-19)

  • Initial version with record() that can record database queries and cache operations and error if they change between test runs.
Release History

Release History

1.1.1

This version

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

1.1.0

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

1.0.4

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

1.0.3

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

1.0.2

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

1.0.1

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

1.0.0

History Node

TODO: Figure out how to actually get changelog content.

Changelog content for this version goes here.

Donec et mollis dolor. Praesent et diam eget libero egestas mattis sit amet vitae augue. Nam tincidunt congue enim, ut porta lorem lacinia consectetur. Donec ut libero sed arcu vehicula ultricies a non tortor. Lorem ipsum dolor sit amet, consectetur adipiscing elit.

Show More

Download Files

Download Files

TODO: Brief introduction on what you do with files - including link to relevant help section.

File Name & Checksum SHA256 Checksum Help Version File Type Upload Date
django_perf_rec-1.1.1-py2.py3-none-any.whl (17.9 kB) Copy SHA256 Checksum SHA256 2.7 Wheel Oct 30, 2016
django-perf-rec-1.1.1.tar.gz (18.0 kB) Copy SHA256 Checksum SHA256 Source Oct 30, 2016

Supported By

WebFaction WebFaction Technical Writing Elastic Elastic Search Pingdom Pingdom Monitoring Dyn Dyn DNS HPE HPE Development Sentry Sentry Error Logging CloudAMQP CloudAMQP RabbitMQ Heroku Heroku PaaS Kabu Creative Kabu Creative UX & Design Fastly Fastly CDN DigiCert DigiCert EV Certificate Rackspace Rackspace Cloud Servers DreamHost DreamHost Log Hosting