ownCloud

This wiki lists the steps required to run our ownCloud comparison experiment from the paper (figure 11).

ownCloud Harness

Our ownCloud harness uses an application scenario we adapted from ownCloud. This is a file sharing application, where users create files and then share them with other users. The applications also supports groups of users, and allows sharing a file with a group as well. During priming, the harness creates users, groups (and their members), and files. Our load consists of the following operations: (1) querying all files shared with some user (directly or indirectly via a group), (2) retrieving a file by its primary key, (3) sharing a file with a user or a group, and (4) updating the file given its primary key. The first two operations are reads, while the last two are writes. Our harness batches several operations of the same type into a single request to minimize network overheads. We configure the harness to exhibit 95% reads and 5% writes, as is common in web-applications.

Our ownCloud harness is single threaded. We run it on the same instance that is running the database server. The harness has three modes: (1) using K9db, (2) using MariaDB, and (3) using MariaDB+memcached.

When run against K9db, the harness wraps the initial creation of groups and files in Compliance transactions, as the item is temporarily orphaned upon creation, and gets assigned to users immediately after when the first corresponding group member or file share is inserted. With MariaDB, the harness does not use Compliance transactions, but perform bulk inserts during priming to speed it up (which our K9db implementation does not currently support). As for MariaDB+memcached, the harness primes as with MariaDB, and starts with an empty cache. Every time an item is queried, the harness first checks if it exists in the cache, and otherwise queries it from MariaDB and adds it to the cache. Write operations invalidate the relevant cache entries. When running the harness with MariaDB+memcached, we execute a warmup stage after priming so that the cache is somewhat populated.

The harness accepts multiple parameters, including the number of users, the number of files per user, and the direct and indirect (i.e. via group) shares per file. It also accepts parameters to control the number of groups and the number of members they have. We use a zipf distribution to share files with users and groups, but the harness can be configured to use a different zipf scale parameter (or uniform). Check our experiment script and the harness help menu for a complete list of parameters.

ownCloud Comparison Experiment (Figure 11)

You can run our experiment by sshing into a pre-configured instance, and running the experiment script. On our setup, this takes about 25 minutes.

cd <K9DB_DIR>
./experiments/scripts/owncloud.sh

When the experiment finishes, it will produce a plot corresponding to figure 11 in experiments/scripts/outputs/owncloud/. The harness output logs can be found at experiments/scripts/logs/owncloud/.

By default, the experiment script produces a simple plot with no cuts. The plotting script experiments/scripts/plotting/owncloud-comparison.py takes an optional --cuts parameter, which you can use to add a horizontal cut to the figure, similar to our paper.

# After running the experiment script to take measurements.
cd experiments/scripts/plotting/
. venv/bin/activate
python owncloud-comparison.py --paper --cuts="(0,1),(1,13)"
# Splits the yaxis into two region, the first spanning y=[0, 1], and the second spanning [1, 13].
# Each region is scaled to use 50% of the area.