[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