From 7adf905b9f468b8e71599fbbc2097e77cb61cb0c Mon Sep 17 00:00:00 2001 From: Zooko O'Whielacronx Date: Sat, 3 Jan 2009 11:41:09 -0700 Subject: [PATCH] immutable: further loosen the performance-regression test to allow up to 45 reads This does raise the question of if there is any point to this test, since I apparently don't know what the answer *should* be, and whenever one of the buildbots fails then I redefine success. But, I'm about to commit a bunch of patches to implement checker, verifier, and repairer as well as to refactor downloader, and I would really like to know if these patches *increase* the number of reads required even higher than it currently is. --- src/allmydata/test/test_immutable.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/allmydata/test/test_immutable.py b/src/allmydata/test/test_immutable.py index 9afaff39..dd4da451 100644 --- a/src/allmydata/test/test_immutable.py +++ b/src/allmydata/test/test_immutable.py @@ -441,11 +441,11 @@ class Test(ShareManglingMixin, unittest.TestCase): def _after_attempt(unused=None): after_download_reads = self._count_reads() # To pass this test, you are required to give up before reading all of the share - # data. Actually, we could give up sooner than 39 reads, but currently our download - # code does 39 reads. This test then serves as a "performance regression detector" + # data. Actually, we could give up sooner than 45 reads, but currently our download + # code does 45 reads. This test then serves as a "performance regression detector" # -- if you change download code so that it takes *more* reads, then this test will # fail. - self.failIf(after_download_reads-before_download_reads > 39, (after_download_reads, before_download_reads)) + self.failIf(after_download_reads-before_download_reads > 45, (after_download_reads, before_download_reads)) d.addCallback(_after_attempt) return d -- 2.45.2