ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2024-12-20 13:33:09 +00:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

immutable: further loosen the performance-regression test to allow up to 45 reads

Browse Source 
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.
This commit is contained in:
Zooko O'Whielacronx 2009-01-03 11:41:09 -07:00
parent 2788c80496
commit 7adf905b9f
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
src/allmydata/test/test_immutable.py
View File

@ -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