@olasd these are the failed dependencies you told me to expect, right? The missing package is ... libcmph-dev.

I'd like to create a new package ( swh-objstorage-hash) and https://docs.softwareheritage.org/devel/tutorials/add-new-package.html is presumably the guide to do that. I however do not have the required permissions: would someone be so kind as to work with me on this?

make it more readable as suggested

I agree

Trvial bugfix https://forge.softwareheritage.org/D6417

it make sense to create a dedicated swh-perfecthash package.

That I did not know, so indeed, if we need a specific wrapper for our needs, ...

In addition to being unmaintained,

this could be addressed by asking authors to be in charge of the package

SWH I guess: I don't see the difference whether it's embedded in swh-objstorage, winery or a dedicated package.

That was just a test, trash it.

tox is called with explicit -e, adding a new environment is a noop unless the matching jenkins job is updated

SWH I guess: I don't see the difference whether it's embedded in swh-objstorage, winery or a dedicated package.

Wouldn't it make sense to put the cffi-based cmph wrapper in a dedicated python module/project (not necessarily under the swh namespace)?

@olasd @douardda @thomash05 : the following passes tox -e py3 therefore it is not complete nonsense. However it raises two questions:

Throttling writes to 120MBs to reduce the pressure:

The number of slow random reads reaches ~3.5% presumably because there is too much write pressure (the throttling of writes was removed).

The benchmarks were modified to (i) use a fixed number of random / sequential readers instead of a random choice for better predictability, (ii) introduce throttling to cap the sequential reads speed to approximately 200MB/s. A run of read only was run:

The run terminated August 11th @ 15:21 because of what appears to be a rare race condition. It was however mostly finished. The results show an unexpected degradation in the read performances. It deserves further investigation because it keeps degrading over time. The write performance are however stable and suggest the benchmark code itself may be responsible for this degradation. If the Ceph cluster was globally slowing down, both reads and writes would show a degradation in performance because previous benchmark results showed that there is a correlation between the two.

Improve the readability of the graphs

Rehearse the run and make minor updates to make sure it runs right away this friday.