Stefan Sperling <stsp_at_elego.de> writes:
> When I upgraded a 1.6.x working copy of 2GB size, it took more than one hour.
> I eventually just aborted the upgrade. A checkout completes within
> a couple of minutes.
> The repository is remote and the bottleneck should be my 16MB/s downstream
> link (the server is connected to my ISP via the berlin internet exchange
> at 100Mbit/s). So based on what you're saying I should be seeing a much
> better upgrade vs. checkout ratio.
> Link to the repository: http://svn.dslinux.org/svn/trunk
> svn also seemed to spend more and more time hogging the CPU as the upgrade
> progressed. Note: I have not profiled this, it is all based on what I
> perceived while waiting for the upgrade to complete, and I kept box getting
> more and more impatiant. I'd be willing to repeat this experiment with a
> pr filed build.
Moving from IRC to dev.
We fixed some SQL queries that were not using indices, so upgrade now
scales much better but it is still not as fast as checkout. On my
I can improve the speed further by increasing the SQLite cache size from
2,000 to 200,000 pages:
1.6-1.7 upgrade cache x100
This cache increase has only a small effect on checkout:
1.7 checkout cache x100
and that might be down to my connection. The cache's different effect
on upgrade/checkout may be because upgrade is a single, large
transaction while checkout is a series of small transactions.
I suspect that part of the performance problem for upgrade is that it
involves reads and writes to the same disk. Just copying using cp(1)
the pristine directory takes minutes on this machine. By contrast
checkout is mostly just writes. A RAID array to improve upgrade, or a
slower network connection to degrade checkout, would probably alter the
Running "svn status" on this large (2.4G in 1.6, 2.0G in 1.7) working
copy shows that 1.7 is faster than 1.6 with a cold cache (50s to 80s)
but slower with a hot cache (1.8s to 1.4s).
Received on 2011-06-28 18:43:42 CEST