|
1
|
<title>Fossil Performance</title> |
|
2
|
|
|
3
|
The questions will inevitably arise: How does Fossil perform? |
|
4
|
Does it use a lot of disk space or bandwidth? Is it scalable? |
|
5
|
|
|
6
|
In an attempt to answer these questions, this report looks at several |
|
7
|
projects that use fossil for configuration management and examines how |
|
8
|
well they are working. The following table is a summary of the results. |
|
9
|
(Last updated on 2018-06-04.) |
|
10
|
Explanation and analysis follows the table. |
|
11
|
|
|
12
|
<table> |
|
13
|
<tr> |
|
14
|
<th>Project</th> |
|
15
|
<th>Number Of Artifacts</th> |
|
16
|
<th>Number Of Check-ins</th> |
|
17
|
<th>Project Duration<br>(as of 2018-06-04)</th> |
|
18
|
<th>Uncompressed Size</th> |
|
19
|
<th>Repository Size</th> |
|
20
|
<th>Compression Ratio</th> |
|
21
|
<th>Clone Bandwidth</th> |
|
22
|
</tr> |
|
23
|
|
|
24
|
<tr align="center"> |
|
25
|
<td>[http://www.sqlite.org/src/timeline | SQLite] |
|
26
|
<td>77492 |
|
27
|
<td>20686 |
|
28
|
<td>6580 days<br>18.02 years |
|
29
|
<td>5.6 GB |
|
30
|
<td>70.0 MB |
|
31
|
<td>80:1 |
|
32
|
<td>51.1 MB |
|
33
|
</tr> |
|
34
|
|
|
35
|
<tr align="center"> |
|
36
|
<td>[http://core.tcl.tk/tcl/timeline | TCL] |
|
37
|
<td>161991 |
|
38
|
<td>23146 |
|
39
|
<td>7375 days<br>20.19 years |
|
40
|
<td>8.0 GB |
|
41
|
<td>222.0 MB |
|
42
|
<td>36:1 |
|
43
|
<td>150.5 MB |
|
44
|
</tr> |
|
45
|
|
|
46
|
<tr align="center"> |
|
47
|
<td>[/timeline | Fossil] |
|
48
|
<td>39148 |
|
49
|
<td>11266 |
|
50
|
<td>3971 days<br>10.87 years |
|
51
|
<td>3.8 GB |
|
52
|
<td>42.0 MB |
|
53
|
<td>90:1 |
|
54
|
<td>27.4 MB |
|
55
|
</tr> |
|
56
|
|
|
57
|
<tr align="center"> |
|
58
|
<td>[http://www.sqlite.org/slt/timeline | SLT] |
|
59
|
<td>2384 |
|
60
|
<td>169 |
|
61
|
<td>3474 days<br>9.51 years |
|
62
|
<td>2.1 GB |
|
63
|
<td>145.9 MB |
|
64
|
<td>14:1 |
|
65
|
<td>143.4 MB |
|
66
|
</tr> |
|
67
|
|
|
68
|
<tr align="center"> |
|
69
|
<td>[http://www.sqlite.org/th3.html | TH3] |
|
70
|
<td>12406 |
|
71
|
<td>3718 |
|
72
|
<td>3539 days<br>9.69 years |
|
73
|
<td>544 MB |
|
74
|
<td>18.0 MB |
|
75
|
<td>30:1 |
|
76
|
<td>14.7 MB |
|
77
|
</tr> |
|
78
|
|
|
79
|
<tr align="center"> |
|
80
|
<td>[http://www.sqlite.org/docsrc/timeline | SQLite Docs] |
|
81
|
<td>8752 |
|
82
|
<td>2783 |
|
83
|
<td>3857 days<br>10.56 years |
|
84
|
<td>349.9 MB |
|
85
|
<td>16.3 MB |
|
86
|
<td>21:1 |
|
87
|
<td>13.57 MB |
|
88
|
</tr> |
|
89
|
|
|
90
|
</table> |
|
91
|
|
|
92
|
<h2>Measured Attributes</h2> |
|
93
|
|
|
94
|
In Fossil, every version of every file, every wiki page, every change to |
|
95
|
every ticket, and every check-in is a separate "artifact". One way to |
|
96
|
think of a Fossil project is as a bag of artifacts. Of course, there is |
|
97
|
a lot more than this going on in Fossil. Many of the artifacts have meaning |
|
98
|
and are related to other artifacts. But at a low level (for example when |
|
99
|
synchronizing two instances of the same project) the only thing that matters |
|
100
|
is the unordered collection of artifacts. In fact, one of the key |
|
101
|
characteristics of Fossil is that the entire project history can be |
|
102
|
reconstructed simply by scanning the artifacts in an arbitrary order. |
|
103
|
|
|
104
|
The number of check-ins is the number of times that the "commit" command |
|
105
|
has been run. A single check-in might change 3 or 4 files, or it might |
|
106
|
change dozens or hundreds of files. Regardless of the number of files |
|
107
|
changed, it still only counts as one check-in. |
|
108
|
|
|
109
|
The "Uncompressed Size" is the total size of all the artifacts within |
|
110
|
the repository assuming they were all uncompressed and stored |
|
111
|
separately on the disk. Fossil makes use of delta compression between related |
|
112
|
versions of the same file, and then uses zlib compression on the resulting |
|
113
|
deltas. The total resulting repository size is shown after the uncompressed |
|
114
|
size. |
|
115
|
|
|
116
|
On the right end of the table, we show the "Clone Bandwidth". This is the |
|
117
|
total number of bytes sent from server back to the client. The number of |
|
118
|
bytes sent from client to server is negligible in comparison. |
|
119
|
These byte counts include HTTP protocol overhead. |
|
120
|
|
|
121
|
In the table and throughout this article, |
|
122
|
"GB" means gigabytes (10<sup><small>9</small></sup> bytes) |
|
123
|
not <a href="http://en.wikipedia.org/wiki/Gibibyte">gibibytes</a> |
|
124
|
(2<sup><small>30</small></sup> bytes). Similarly, "MB" and "KB" |
|
125
|
means megabytes and kilobytes, not mebibytes and kibibytes. |
|
126
|
|
|
127
|
<h2>Analysis And Supplemental Data</h2> |
|
128
|
|
|
129
|
Perhaps the two most interesting data points in the above table are SQLite |
|
130
|
and SLT. SQLite is a long-running project with long revision chains. |
|
131
|
Some of the files in SQLite have been edited over a thousand times. |
|
132
|
Each of these edits is stored as a delta, and hence the SQLite project |
|
133
|
gets excellent 80:1 compression. SLT, on the other hand, consists of |
|
134
|
many large (megabyte-sized) SQL scripts that have one or maybe two |
|
135
|
edits each. There is very little delta compression occurring and so the |
|
136
|
overall repository compression ratio is much lower. Note also that |
|
137
|
quite a bit more bandwidth is required to clone SLT than SQLite. |
|
138
|
|
|
139
|
For the first nine years of its development, SQLite was versioned by CVS. |
|
140
|
The resulting CVS repository measured over 320MB in size. So, the |
|
141
|
developers were surprised to see that the equivalent Fossil project (the |
|
142
|
first nine years on SQLite) would clone with only 13MB of bandwidth. |
|
143
|
The "sync" protocol |
|
144
|
used by fossil has turned out to be surprisingly efficient. A typical |
|
145
|
check-in on SQLite might use 3 or 4KB of network bandwidth. |
|
146
|
For example, the [04eef9522386a59e] check-in used a single HTTP request |
|
147
|
of 2099 bytes and got back a reply of 1116 bytes. |
|
148
|
The sync protocol is efficient enough that, once cloned, |
|
149
|
Fossil can easily be used over a dial-up connection. |
|
150
|
|