unit tests take too long #20
Labels
No labels
c/code
c/code-dirnodes
c/code-encoding
c/code-frontend
c/code-frontend-cli
c/code-frontend-ftp-sftp
c/code-frontend-magic-folder
c/code-frontend-web
c/code-mutable
c/code-network
c/code-nodeadmin
c/code-peerselection
c/code-storage
c/contrib
c/dev-infrastructure
c/docs
c/operational
c/packaging
c/unknown
c/website
kw:2pc
kw:410
kw:9p
kw:ActivePerl
kw:AttributeError
kw:DataUnavailable
kw:DeadReferenceError
kw:DoS
kw:FileZilla
kw:GetLastError
kw:IFinishableConsumer
kw:K
kw:LeastAuthority
kw:Makefile
kw:RIStorageServer
kw:StringIO
kw:UncoordinatedWriteError
kw:about
kw:access
kw:access-control
kw:accessibility
kw:accounting
kw:accounting-crawler
kw:add-only
kw:aes
kw:aesthetics
kw:alias
kw:aliases
kw:aliens
kw:allmydata
kw:amazon
kw:ambient
kw:annotations
kw:anonymity
kw:anonymous
kw:anti-censorship
kw:api_auth_token
kw:appearance
kw:appname
kw:apport
kw:archive
kw:archlinux
kw:argparse
kw:arm
kw:assertion
kw:attachment
kw:auth
kw:authentication
kw:automation
kw:avahi
kw:availability
kw:aws
kw:azure
kw:backend
kw:backoff
kw:backup
kw:backupdb
kw:backward-compatibility
kw:bandwidth
kw:basedir
kw:bayes
kw:bbfreeze
kw:beta
kw:binaries
kw:binutils
kw:bitcoin
kw:bitrot
kw:blacklist
kw:blocker
kw:blocks-cloud-deployment
kw:blocks-cloud-merge
kw:blocks-magic-folder-merge
kw:blocks-merge
kw:blocks-raic
kw:blocks-release
kw:blog
kw:bom
kw:bonjour
kw:branch
kw:branding
kw:breadcrumbs
kw:brians-opinion-needed
kw:browser
kw:bsd
kw:build
kw:build-helpers
kw:buildbot
kw:builders
kw:buildslave
kw:buildslaves
kw:cache
kw:cap
kw:capleak
kw:captcha
kw:cast
kw:centos
kw:cffi
kw:chacha
kw:charset
kw:check
kw:checker
kw:chroot
kw:ci
kw:clean
kw:cleanup
kw:cli
kw:cloud
kw:cloud-backend
kw:cmdline
kw:code
kw:code-checks
kw:coding-standards
kw:coding-tools
kw:coding_tools
kw:collection
kw:compatibility
kw:completion
kw:compression
kw:confidentiality
kw:config
kw:configuration
kw:configuration.txt
kw:conflict
kw:connection
kw:connectivity
kw:consistency
kw:content
kw:control
kw:control.furl
kw:convergence
kw:coordination
kw:copyright
kw:corruption
kw:cors
kw:cost
kw:coverage
kw:coveralls
kw:coveralls.io
kw:cpu-watcher
kw:cpyext
kw:crash
kw:crawler
kw:crawlers
kw:create-container
kw:cruft
kw:crypto
kw:cryptography
kw:cryptography-lib
kw:cryptopp
kw:csp
kw:curl
kw:cutoff-date
kw:cycle
kw:cygwin
kw:d3
kw:daemon
kw:darcs
kw:darcsver
kw:database
kw:dataloss
kw:db
kw:dead-code
kw:deb
kw:debian
kw:debug
kw:deep-check
kw:defaults
kw:deferred
kw:delete
kw:deletion
kw:denial-of-service
kw:dependency
kw:deployment
kw:deprecation
kw:desert-island
kw:desert-island-build
kw:design
kw:design-review-needed
kw:detection
kw:dev-infrastructure
kw:devpay
kw:directory
kw:directory-page
kw:dirnode
kw:dirnodes
kw:disconnect
kw:discovery
kw:disk
kw:disk-backend
kw:distribute
kw:distutils
kw:dns
kw:do_http
kw:doc-needed
kw:docker
kw:docs
kw:docs-needed
kw:dokan
kw:dos
kw:download
kw:downloader
kw:dragonfly
kw:drop-upload
kw:duplicity
kw:dusty
kw:earth-dragon
kw:easy
kw:ec2
kw:ecdsa
kw:ed25519
kw:egg-needed
kw:eggs
kw:eliot
kw:email
kw:empty
kw:encoding
kw:endpoint
kw:enterprise
kw:enum34
kw:environment
kw:erasure
kw:erasure-coding
kw:error
kw:escaping
kw:etag
kw:etch
kw:evangelism
kw:eventual
kw:example
kw:excess-authority
kw:exec
kw:exocet
kw:expiration
kw:extensibility
kw:extension
kw:failure
kw:fedora
kw:ffp
kw:fhs
kw:figleaf
kw:file
kw:file-descriptor
kw:filename
kw:filesystem
kw:fileutil
kw:fips
kw:firewall
kw:first
kw:floatingpoint
kw:flog
kw:foolscap
kw:forward-compatibility
kw:forward-secrecy
kw:forwarding
kw:free
kw:freebsd
kw:frontend
kw:fsevents
kw:ftp
kw:ftpd
kw:full
kw:furl
kw:fuse
kw:garbage
kw:garbage-collection
kw:gateway
kw:gatherer
kw:gc
kw:gcc
kw:gentoo
kw:get
kw:git
kw:git-annex
kw:github
kw:glacier
kw:globalcaps
kw:glossary
kw:google-cloud-storage
kw:google-drive-backend
kw:gossip
kw:governance
kw:grid
kw:grid-manager
kw:gridid
kw:gridsync
kw:grsec
kw:gsoc
kw:gvfs
kw:hackfest
kw:hacktahoe
kw:hang
kw:hardlink
kw:heartbleed
kw:heisenbug
kw:help
kw:helper
kw:hint
kw:hooks
kw:how
kw:how-to
kw:howto
kw:hp
kw:hp-cloud
kw:html
kw:http
kw:https
kw:i18n
kw:i2p
kw:i2p-collab
kw:illustration
kw:image
kw:immutable
kw:impressions
kw:incentives
kw:incident
kw:init
kw:inlineCallbacks
kw:inotify
kw:install
kw:installer
kw:integration
kw:integration-test
kw:integrity
kw:interactive
kw:interface
kw:interfaces
kw:interoperability
kw:interstellar-exploration
kw:introducer
kw:introduction
kw:iphone
kw:ipkg
kw:iputil
kw:ipv6
kw:irc
kw:jail
kw:javascript
kw:joke
kw:jquery
kw:json
kw:jsui
kw:junk
kw:key-value-store
kw:kfreebsd
kw:known-issue
kw:konqueror
kw:kpreid
kw:kvm
kw:l10n
kw:lae
kw:large
kw:latency
kw:leak
kw:leasedb
kw:leases
kw:libgmp
kw:license
kw:licenss
kw:linecount
kw:link
kw:linux
kw:lit
kw:localhost
kw:location
kw:locking
kw:logging
kw:logo
kw:loopback
kw:lucid
kw:mac
kw:macintosh
kw:magic-folder
kw:manhole
kw:manifest
kw:manual-test-needed
kw:map
kw:mapupdate
kw:max_space
kw:mdmf
kw:memcheck
kw:memory
kw:memory-leak
kw:mesh
kw:metadata
kw:meter
kw:migration
kw:mime
kw:mingw
kw:minimal
kw:misc
kw:miscapture
kw:mlp
kw:mock
kw:more-info-needed
kw:mountain-lion
kw:move
kw:multi-users
kw:multiple
kw:multiuser-gateway
kw:munin
kw:music
kw:mutability
kw:mutable
kw:mystery
kw:names
kw:naming
kw:nas
kw:navigation
kw:needs-review
kw:needs-spawn
kw:netbsd
kw:network
kw:nevow
kw:new-user
kw:newcaps
kw:news
kw:news-done
kw:news-needed
kw:newsletter
kw:newurls
kw:nfc
kw:nginx
kw:nixos
kw:no-clobber
kw:node
kw:node-url
kw:notification
kw:notifyOnDisconnect
kw:nsa310
kw:nsa320
kw:nsa325
kw:numpy
kw:objects
kw:old
kw:openbsd
kw:openitp-packaging
kw:openssl
kw:openstack
kw:opensuse
kw:operation-helpers
kw:operational
kw:operations
kw:ophandle
kw:ophandles
kw:ops
kw:optimization
kw:optional
kw:options
kw:organization
kw:os
kw:os.abort
kw:ostrom
kw:osx
kw:osxfuse
kw:otf-magic-folder-objective1
kw:otf-magic-folder-objective2
kw:otf-magic-folder-objective3
kw:otf-magic-folder-objective4
kw:otf-magic-folder-objective5
kw:otf-magic-folder-objective6
kw:p2p
kw:packaging
kw:partial
kw:password
kw:path
kw:paths
kw:pause
kw:peer-selection
kw:performance
kw:permalink
kw:permissions
kw:persistence
kw:phone
kw:pickle
kw:pip
kw:pipermail
kw:pkg_resources
kw:placement
kw:planning
kw:policy
kw:port
kw:portability
kw:portal
kw:posthook
kw:pratchett
kw:preformance
kw:preservation
kw:privacy
kw:process
kw:profile
kw:profiling
kw:progress
kw:proxy
kw:publish
kw:pyOpenSSL
kw:pyasn1
kw:pycparser
kw:pycrypto
kw:pycrypto-lib
kw:pycryptopp
kw:pyfilesystem
kw:pyflakes
kw:pylint
kw:pypi
kw:pypy
kw:pysqlite
kw:python
kw:python3
kw:pythonpath
kw:pyutil
kw:pywin32
kw:quickstart
kw:quiet
kw:quotas
kw:quoting
kw:raic
kw:rainhill
kw:random
kw:random-access
kw:range
kw:raspberry-pi
kw:reactor
kw:readonly
kw:rebalancing
kw:recovery
kw:recursive
kw:redhat
kw:redirect
kw:redressing
kw:refactor
kw:referer
kw:referrer
kw:regression
kw:rekey
kw:relay
kw:release
kw:release-blocker
kw:reliability
kw:relnotes
kw:remote
kw:removable
kw:removable-disk
kw:rename
kw:renew
kw:repair
kw:replace
kw:report
kw:repository
kw:research
kw:reserved_space
kw:response-needed
kw:response-time
kw:restore
kw:retrieve
kw:retry
kw:review
kw:review-needed
kw:reviewed
kw:revocation
kw:roadmap
kw:rollback
kw:rpm
kw:rsa
kw:rss
kw:rst
kw:rsync
kw:rusty
kw:s3
kw:s3-backend
kw:s3-frontend
kw:s4
kw:same-origin
kw:sandbox
kw:scalability
kw:scaling
kw:scheduling
kw:schema
kw:scheme
kw:scp
kw:scripts
kw:sdist
kw:sdmf
kw:security
kw:self-contained
kw:server
kw:servermap
kw:servers-of-happiness
kw:service
kw:setup
kw:setup.py
kw:setup_requires
kw:setuptools
kw:setuptools_darcs
kw:sftp
kw:shared
kw:shareset
kw:shell
kw:signals
kw:simultaneous
kw:six
kw:size
kw:slackware
kw:slashes
kw:smb
kw:sneakernet
kw:snowleopard
kw:socket
kw:solaris
kw:space
kw:space-efficiency
kw:spam
kw:spec
kw:speed
kw:sqlite
kw:ssh
kw:ssh-keygen
kw:sshfs
kw:ssl
kw:stability
kw:standards
kw:start
kw:startup
kw:static
kw:static-analysis
kw:statistics
kw:stats
kw:stats_gatherer
kw:status
kw:stdeb
kw:storage
kw:streaming
kw:strports
kw:style
kw:stylesheet
kw:subprocess
kw:sumo
kw:survey
kw:svg
kw:symlink
kw:synchronous
kw:tac
kw:tahoe-*
kw:tahoe-add-alias
kw:tahoe-admin
kw:tahoe-archive
kw:tahoe-backup
kw:tahoe-check
kw:tahoe-cp
kw:tahoe-create-alias
kw:tahoe-create-introducer
kw:tahoe-debug
kw:tahoe-deep-check
kw:tahoe-deepcheck
kw:tahoe-lafs-trac-stream
kw:tahoe-list-aliases
kw:tahoe-ls
kw:tahoe-magic-folder
kw:tahoe-manifest
kw:tahoe-mkdir
kw:tahoe-mount
kw:tahoe-mv
kw:tahoe-put
kw:tahoe-restart
kw:tahoe-rm
kw:tahoe-run
kw:tahoe-start
kw:tahoe-stats
kw:tahoe-unlink
kw:tahoe-webopen
kw:tahoe.css
kw:tahoe_files
kw:tahoewapi
kw:tarball
kw:tarballs
kw:tempfile
kw:templates
kw:terminology
kw:test
kw:test-and-set
kw:test-from-egg
kw:test-needed
kw:testgrid
kw:testing
kw:tests
kw:throttling
kw:ticket999-s3-backend
kw:tiddly
kw:time
kw:timeout
kw:timing
kw:to
kw:to-be-closed-on-2011-08-01
kw:tor
kw:tor-protocol
kw:torsocks
kw:tox
kw:trac
kw:transparency
kw:travis
kw:travis-ci
kw:trial
kw:trickle
kw:trivial
kw:truckee
kw:tub
kw:tub.location
kw:twine
kw:twistd
kw:twistd.log
kw:twisted
kw:twisted-14
kw:twisted-trial
kw:twitter
kw:twn
kw:txaws
kw:type
kw:typeerror
kw:ubuntu
kw:ucwe
kw:ueb
kw:ui
kw:unclean
kw:uncoordinated-writes
kw:undeletable
kw:unfinished-business
kw:unhandled-error
kw:unhappy
kw:unicode
kw:unit
kw:unix
kw:unlink
kw:update
kw:upgrade
kw:upload
kw:upload-helper
kw:uri
kw:url
kw:usability
kw:use-case
kw:utf-8
kw:util
kw:uwsgi
kw:ux
kw:validation
kw:variables
kw:vdrive
kw:verify
kw:verlib
kw:version
kw:versioning
kw:versions
kw:video
kw:virtualbox
kw:virtualenv
kw:vista
kw:visualization
kw:visualizer
kw:vm
kw:volunteergrid2
kw:volunteers
kw:vpn
kw:wapi
kw:warners-opinion-needed
kw:warning
kw:weapi
kw:web
kw:web.port
kw:webapi
kw:webdav
kw:webdrive
kw:webport
kw:websec
kw:website
kw:websocket
kw:welcome
kw:welcome-page
kw:welcomepage
kw:wiki
kw:win32
kw:win64
kw:windows
kw:windows-related
kw:winscp
kw:workaround
kw:world-domination
kw:wrapper
kw:write-enabler
kw:wui
kw:x86
kw:x86-64
kw:xhtml
kw:xml
kw:xss
kw:zbase32
kw:zetuptoolz
kw:zfec
kw:zookos-opinion-needed
kw:zope
kw:zope.interface
p/blocker
p/critical
p/major
p/minor
p/normal
p/supercritical
p/trivial
r/cannot reproduce
r/duplicate
r/fixed
r/invalid
r/somebody else's problem
r/was already fixed
r/wontfix
r/worksforme
t/defect
t/enhancement
t/task
v/0.2.0
v/0.3.0
v/0.4.0
v/0.5.0
v/0.5.1
v/0.6.0
v/0.6.1
v/0.7.0
v/0.8.0
v/0.9.0
v/1.0.0
v/1.1.0
v/1.10.0
v/1.10.1
v/1.10.2
v/1.10a2
v/1.11.0
v/1.12.0
v/1.12.1
v/1.13.0
v/1.14.0
v/1.15.0
v/1.15.1
v/1.2.0
v/1.3.0
v/1.4.1
v/1.5.0
v/1.6.0
v/1.6.1
v/1.7.0
v/1.7.1
v/1.7β
v/1.8.0
v/1.8.1
v/1.8.2
v/1.8.3
v/1.8β
v/1.9.0
v/1.9.0-s3branch
v/1.9.0a1
v/1.9.0a2
v/1.9.0b1
v/1.9.1
v/1.9.2
v/1.9.2a1
v/cloud-branch
v/unknown
No milestone
No project
No assignees
6 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: tahoe-lafs/trac#20
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The best way to fix this would be to optimize the code under test so that it passes the tests faster.
The second best way would be to optimize the tests so that they test the same thing but faster.
The third best way would be to reduce the "replications, redundancy, random stabs in the dark" and so forth, and the tests of scaling. (This cries out for another category of test that reports on scaling behavior...)
The fourth best way would be to judiciously prune tests which have been superceded by more comprehensive tests and are now redundant.
one source of improvement would be the test_encode.Encode.test_send_NNN tests which seek to cover fencepost issues on both the size of the plaintext (relative to the segment size) and the number of segments (relative to the power-of-two size of the block hash tree).
At the moment this is using 100 shares per test, while we could probably get the same test coverage by using 10 share per test.
On the other hand, test_encode appears to take about 1% of the total test time on my system. test_system takes 4%.
curiously, the 'dapper' buildslave just went from taking 40+ minutes to run the test suite down to 12 minutes. I'm not quite sure how it helped, but the proximate change was to remove the .pyc files before running the tests: the build process (that whole setup.py install --prefix/--root thing) seems to put bogus source file names in the .pyc files, messing up stack traces and figleaf output.
For at least one test run (on the edgy buildslave), I used 'strace' to watch the test's progress, and I saw a whole boatload of futex() syscalls interspersed with failed attempts to open (or maybe just access()) bogus .py filenames that started with /lib . It feels like something was trying to find its source code, failing, and not cacheing the failure. There weren't a lot of stack traces taking place at the time (it was in the middle of test_system, somewhere between send_block_hashes and close_buckets), at least none that made it into the logs.
Oh! But, if Deferred debugging were turned on, that would capture a stack trace inside every single Deferred, both at creation and at invocation. If it were trying to open a source file for those stack traces, that would be a lot of path searching and failed open() calls.
Huh, look at that. Removing the defer.setDebugging(True) from test_introducer.py reduces the time to run the unit tests on my laptop from 1m56s to 55s, a factor of 2. Guess I should fix that.
wow. the dapper buildslave, our slowest, was taking half an hour to run the unit test suite yesterday. After removing defer.setDebugging() (and dealing with the .pyc problem in #35), the dapper buildslave just finished a test run in two minutes. Cool.
I think I can close this ticket now. When we add enough tests for this two minutes to become 10, let's revisit the ideas presented above.
Okay, nowadays it takes about 20 minutes to run our tests on the Dapper buildslave. More troublesome for me is that it takes about 5 minutes to run on my own personal workstation. Hopefully we'll implement #217 (DSA-based mutable files -- small URLs, fast file creation) and that it will help a bit. Also, could we use DSA instead of RSA for foolscap tub ids? Or even unencrypted foolscap with randomly-generated tub ids?
I've considered building a NotQuiteSystemTestMixin framework which would use real storage servers but not real Tubs: to bypass the serialization and network-roundtrip part of the framework. I figure that would cut out a lot of the time spent in system-ish tests.
We're using a lot more SystemTestMixin -style tests these days, partially because it's easier to set up (fewer "fake" objects), partially the system is basically complete (I wrote a lot of unit tests for, say, upload, before there was any code to perform download). The SystemTestMixin takes a second or two just to get initialized and establish all the connections.
Oh, so source:src/allmydata/test/test_mutable.py
LessFakeClient
is basically the framework I was thinking of. It uses real StorageServer instances but doesn't use Foolscap or an introducer. It can create a client and 10 connected storage servers in 7 milliseconds, whereas the usual SystemTestMixin takes 1.4 seconds to construct 5 client+servers and wait for them to connect.Most upload/download operations should be faster too.
On my main workstation, if it happens to be loaded down with other work, it can take more than 15 minutes to run all the tahoe tests. This interferes with my workflow.
Also I see that the cygwin buildslave took about 8 hours to run all the steps of its builder yesterday.
This still definitely takes too long (almost 9 minutes just now). It's quite disruptive.
Also, it would be helpful to document on the Dev page how to run a subset of the tests (I did work out how to do this but I've already forgotten the incantation).
davidsarah, where would such documentation live? I thought it would be better in the source:docs directory than on the wiki, but examining both places I didn't see a natural place to describe it. Anyway the description that should be added might include a link to http://twistedmatrix.com/trac/wiki/TwistedTrial plus the specific tip that
trial allmydata.test.test_module.TestClass.test_func
is the way to run just one func, and likewise for other prefixes of that test identifier.FYI, "trial $TESTNAME" doesn't work, because it doesn't set up PYTHONPATH and PATH and whatnot. I use
make quicktest TEST=$TESTNAME
. Usingmake test TEST=$TESTNAME
does something similar, but also does a rebuild first, which adds maybe 10 seconds and an awful lot of noise (but works right after a source checkout, whereas quicktest requires an explicit build first).python setup.py test -s $TESTNAME
is equivalent tomake test TEST=$TESTNAME
, since the latter is implemented in terms of the former.We could probably add a "developers.txt" file to the docs/ directory.. this hint could live there, along with how-is-the-code-organized and maybe a description of the various Makefile/setup.py commands that are available. OTOH, I usually just look for these descriptions in the Makefile and setup.py, so putting them elsewhere seems a bit weird.
An interesting next-step would be to turn on the profiler feature of trial and see which Python functions are taking the most time. :-)
The first person who submits a patch that reduces runtime of the full unit test suite, on Brian's laptop, by 20%, without causing any code to be less covered by tests, will receive 50 ⓑ from me. (Current market value, about $250.00.)
Offer good until I change my mind, so hurry up.
Oh wait, did I say reduce by 20%? I changed my mind. To get my 50ⓑ, you have to make it 5X faster—in other words take 20% of the total runtime—on Brian's laptop.
Note that Brian's laptop has some kind of performance problem with disk I/O, such that unit tests take about 24 minutes on there, compared to these runtimes on our buildslaves:
https://tahoe-lafs.org/buildbot-tahoe-lafs/builders/lucid-amd64/builds/58
12 minutes
https://tahoe-lafs.org/buildbot-tahoe-lafs/builders/Atlas%20ubuntu%20natty/builds/65/steps/test
15 minutes
https://tahoe-lafs.org/buildbot-tahoe-lafs/builders/Ruben%20Fedora/builds/65
13 minutes
https://tahoe-lafs.org/buildbot-tahoe-lafs/builders/Kyle%20OpenBSD%20amd64/builds/72
10 minutes.
So you might be able to win by finding figuring out where our unit tests are relying on disk I/O and replacing those parts of the unit tests with in-memory fake objects. That would almost certainly not lose coverage over any line of code.
I probably won't change my mind again for at least a few days, so get crackin'!
In the unlikely and happy circumstance that more than one person posts a winning patch, the order that they appear as attachments to this ticket will determine who has priority. Also, if someone else wins, but you post a patch which is both original (you didn't copy it from the winner) and has some independent value (it contains code which we might like to adopt even after we adopted the winner's), then I might consider giving you a consolation prize of Bitcoin.
I won't have time to work on this ticket, but here are some ideas:
_trial_temp
in a tmpfs.To test the first of these, I created a tmpfs using
sudo mount -t tmpfs -o size=330m tmpfs _trial_temp
, and hacked Twisted Trial so that it would just use this existing directory rather than trying to delete and recreate it.Timings for
time bin/tahoe debug trial
on my machine with_trial_temp
on disk:Corresponding timings with
_trial_temp
on a tmpfs:Notice that the user CPU time is only slightly reduced, but the real time is reduced by ~36%, consistent with a significant improvement in I/O wait time. The machine was under memory pressure and I would expect the results to be even better if it hadn't been.
The 330 MiB tmpfs could be smaller if the test suite was optimized to not write as much (or to delete files created for tests that pass).
Sigh, should have thought of the tmpfs idea in the hour between comment:360406 and comment:360407 ;-)
Incidentally, the test run in comment:360409 left ~324 MiB of memory being used by the tmpfs, so the approach would obviously need more work to be acceptable for general use.
FYI, on my work laptop (2010 MacBookPro, with OS-X "Snow Leopard" Filevault non-FDE encrypted home directory), the full test suite (current git master, 8aa690b) takes 27m48s to run, of which 7m23s is "user" and 17m19s is "sys", and leaves 233MiB in
_trial_temp
(of which 118MiB isallmydata.test.test_mutable
, 54MiB iscli
, and 5-10MiB are used bysystem
,repairer
,dirnode
,test_upload
,test_download
,hung_server
, andtest_encode
).That feels like an awful lot of data being generated. I'd start by looking at test_mutable and seeing if we can get rid of most of the k=N=255 cases. We probably need to keep one of them to exercise that end of the encoding spectrum, but I really doubt we need to do it for every single test_mutable case.
I'd also walk though the tests that upload data and look at the filesizes they're using. Many are casually creating 10MB files, resulting in 30MB of shares. We really don't need to cover more than a few segments, so 1MB should be plenty, and in most cases we should be able to lower the min-segment-size to cover a multi-segment file with just a few kB.
I'd also look into moving most tests to use the common NoNetworkGrid class, and make sure that it's using fake server connections to avoid the SSL spinup time (except for test_system, of course, which needs to exercise the SSL connections too). We have about half a dozen fake-server classes in the test suite, partially because I was too lazy to improve an existing one and decided to create new ones instead. So there's probably some cleanup there that would help.
Replying to davidsarah:
See http://twistedmatrix.com/trac/ticket/1784. Summary: you'll be able to do
when that is released in the next version of Twisted. You'll need a lot of memory though!
Replying to davidsarah:
A better way to do that is using
--temp-directory
: trial will still attempt to delete the directory you specify, so it can't directly be the tmpfs mount, but that's OK as long as it is underneath the tmpfs mount:When done:
These tests:
will spuriously fail because the current directory is not as expected by the test.
Replying to [davidsarah]comment:21:
Pull request for a "
make quickertest
" target is at https://github.com/tahoe-lafs/tahoe-lafs/pull/17. It includes a fix for thetest_runner
failures.Note that, like "
make quicktest
", "make quickertest
" assumes that it is run in a Tahoe-LAFS source distribution that is already built. Use "make quickertest TEST=<testname>
" to run a specific test.... for
make quickertest
only.In changeset:edc1f5f67fb34734:
I noticed today that the full test suite takes 30 minutes on my (slow) linux box. Part of the problem is the size of the files created by the tests: the
_trial_temp
directory has 340MB of data at the end of the run, which is kind of excessive.The worst offender is
test_mutable
, which creates 132MB.test_cli
makes 76MB. The next heaviest ones aretest_system
,test_download
,test_dirnode
,test_upload
, andtest_repairer
, which create 12MB-14MB each. There's another 6 that produce 5-10MB, and the rest are 3MB or less.Note: now that we're on tox, the fastest cycle time for a specific test (when you're doing a tight edit-test-coverage-repeat loop) is something like:
.tox/py27/bin/trial allmydata.test.test_foo.Bar.test_blah
Or:
source .tox/py27/bin/activate
coverage 'which trial' allmydata.test.test_foo.Bar.test_blah
That won't do anything extra (installs, updates, etc). I'm no longer concerned about having a
make quicktest
or the like: virtualenvs are good enough for me now.I'm working on a branch that fixes a bunch of this.
test_mutable
uses smaller uploaded files, and stops exercising the N=255 case, which reduces the time by a factor of 7.test_cli
uses a grid with k=N=1, which reduces it by 50%. Smaller speedups were obtained by using k=N=1 on all other NoNetworkGrid tests that don't actually exercise multiple shares.test_system
is still pretty bad, I haven't yet tried to tackle it.In 594dd26/trunk:
Related: #2845
The test suite is faster now. How fast is fast enough? I don't know. I would love it if I could run the whole test suite locally in zero seconds. That would certainly be fast enough. It's probably not practical, though.
What I can do is run the unit test suite locally on my 4 core laptop in about 120 seconds. This is no doubt largely due to hardware improvements since this ticket was originally filed. However, whatever the reason, 120 seconds doesn't seem absurdly excessive, particularly considering comments on this ticket above are discussing run times of 1000 - 2000 seconds.
We should certainly remain open to further speedups but I think this ticket has served its purpose. Future speedups can fall under the umbrella of some other ticket with a narrower focus.
I decline the Bitcoin offered by Zooko above for observing this current state of affairs (and anyway I don't have Brian's laptop to verify the result).
thanks for closing this!
FWIW,
tox -e py2
on my current Debian/buster laptop currently spends 276 seconds intrial
(and failstest_util.FileUtil.test_create_long_path
for some reason).