/brz/remove-bazaar

To get this branch, use:
bzr branch http://gegoxaren.bato24.eu/bzr/brz/remove-bazaar

« back to all changes in this revision

Viewing changes to doc/developers/performance-use-case-analysis.txt

  • Committer: Robert Collins
  • Date: 2007-05-09 15:36:06 UTC
  • mto: This revision was merged to the branch mainline in revision 2485.
  • Revision ID: robertc@robertcollins.net-20070509153606-m556z2rb3d76b2f3
Incremental push-pull performance anlysis draft.

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/performance-use-case-analysis.txt
1
 
.. This document describes _how_ to do use case analyses and what we want
2
 
.. to get out of them; for the specific cases see the files referenced by
3
 
.. performance-roadmap.txt
4
 
 
5
1
Analysing a specific use case
6
 
=============================
 
2
-----------------------------
7
3
 
8
4
The analysis of a use case needs to provide as outputs:
9
5
 * The functional requirements that the use case has to satisfy.
19
15
   should also be mentioned.
20
16
 
21
17
Performing the analysis
22
 
=======================
 
18
-----------------------
23
19
 
24
20
The analysis needs to be able to define the characteristics of the
25
21
involved disk storage and APIs. That means we need to examine the data
42
38
fine to post-process the annotated text to obtain dotted-revnos.'
43
39
 
44
40
What factors should be considered?
45
 
==================================
 
41
----------------------------------
46
42
 
47
43
Obviously, those that will make for an extremely fast system :). There
48
44
are many possible factors, but the ones I think are most interesting to
53
49
   - The time to get bzr ready to begin the use case.
54
50
 
55
51
- scaling: how does performance change when any of the follow aspects
56
 
  of the system are ratcheted massively up or down:
 
52
   of the system are ratched massively up or down:
57
53
 
58
 
   - number of files/dirs/symlinks/subtrees in a tree (both working and
 
54
   - number of files/dirs/symlinks/subtrees in a tree (both working and 
59
55
     revision trees)
60
56
   - size of any particular file
61
57
   - number of elements within a single directory
75
71
   - bandwidth to the disk storage
76
72
   - latency to perform semantic operations (hpss specific)
77
73
   - bandwidth when performing semantic operations.
78
 
 
79
74
- locality of reference: If an operation requires data that is located
80
 
  within a small region at any point, we often get better performance
81
 
  than with an implementation of the same operation that requires the
82
 
  same amount of data but with a lower locality of reference. Its
83
 
  fairly tricky to add locality of reference after the fact, so I think
84
 
  its worth considering up front.
 
75
   within a small region at any point, we often get better performance 
 
76
   than with an implementation of the same operation that requires the
 
77
   same amount of data but with a lower locality of reference. Its 
 
78
   fairly tricky to add locality of reference after the fact, so I think
 
79
   its worth considering up front.
85
80
 
86
81
Using these factors, to the annotate example we can add that its
87
82
reasonable to do two 'semantic' round trips to the local tree, one to
89
84
measurements, in an ideal world there would be no more than one round
90
85
trip for each semantic operation. What there must not be is one round
91
86
trip per revision involved in the revisionid->dotted number mapping, nor
92
 
per each revision id attributed to a line in the text.
 
87
per each revision id attributed to a line in the text. 
93
88
 
94
89
Not all the items mentioned above are created equal. The analysis should
95
90
include the parameters considered and the common case values for each - the
104
99
Many performance problems only become visible when changing the scaling knobs
105
100
upwards to large trees. On small trees its our baseline performance that drives
106
101
incremental improvements; on large trees its the amount of processing per item
107
 
that drives performance. A significant goal therefore is to keep the amount of
 
102
that drives performance. A significant goal therefore is to keep the amouont of
108
103
data to be processed under control. Ideally we can scale in a sublinear fashion
109
104
for all operations, but we MUST NOT scale even linearly for operations that
110
105
invoke a latency multiplier. For example, reading a file on disk requires