[Twisted-web] [PATCH] nonbuffered cache

Andrew Bennetts andrew-twisted at puzzling.org
Thu Jan 12 17:51:51 MST 2006


On Thu, Jan 12, 2006 at 08:47:22PM +0100, Andrea Arcangeli wrote:
> On Thu, Jan 12, 2006 at 05:06:12PM +0100, Valentino Volonghi wrote:
> > Cool, the patch looks good. I'm going to apply it as soon as there are
> > unittests. Some ideas for unittests is to have a counter on the page and check
> > that it never updates while the pages are cached and similar things.
> 
> The ideal unittest would depend on the timings too. Are unittest allowed
> to depend on the timigs?  However writing the unittest is going to be
> more difficult than writing the feature ;)

Timings are extremely difficult to test reliably, but that doesn't mean you
can't test your code.

Valuable things to test include (assuming I understand the purpose of the patch
correctly):
  - pages are still renderable/retrievable as normal with caching enabled,
  - invalidating the cache manually (rather than relying on timing) causes the
    page to be freshly rendered,
  - two concurrent clients for the same page work -- they get the page they
    expect,
  - and that two concurrent clients for the same page cause the page to be
    generated just once (i.e. request A is received, page starts being
    generated, a request B that occurs while request A is still unfinished
    should not cause a second page generation to occur).

This doesn't make the test suite ensure that caches still get the N pages/sec
throughput you're after -- but it does ensure that they don't break, and that at
a coarse level that it's doing the right things for good performance (e.g. the
last suggestion in that list ensures that someone can't simply replace your
cache infrastructure with no-ops by accident and still have tests pass).

There are probably many other acheivable and worthwhile tests like these you
could do.

It's not a complete solution, but it's a heck of a lot better than nothing!

-Andrew.




More information about the Twisted-web mailing list