... | ... | @@ -54,4 +54,16 @@ Next, we address each item individually to give an account of its current state |
|
|
|
|
|
In July 2017 LEAP launched the https://benchmarks.leap.se/ website, where benchmarking statistics can be seen for every set of commits pushed to Soledad's repository. We currently have time, memory and cpu consumption for each test of a special **benchmarking** set of tests. The solution is based on [elasticsearch](https://www.elastic.co/products/elasticsearch) to store results of benchmarks, [kibana](https://www.elastic.co/products/kibana) to plot graphs, and some custom scripts to glue everything together. Documentation on [how to add more tests to the benchmarking suite and website](http://soledad.readthedocs.io/en/latest/misc/benchmarks-website.html) is available.
|
|
|
|
|
|
As Soledad works with a reactor pattern, it is important to have feedback on possible reactor blocks and the overall reactor responsiveness. This is mostly done, but still not merged (#8908). |
|
|
\ No newline at end of file |
|
|
As Soledad works with a reactor pattern, it is important to have feedback on possible reactor blocks and the overall reactor responsiveness. This is mostly done, but still not merged (#8908).
|
|
|
|
|
|
On our todo list we still have measurement of speed o I/O, server scalability when used by concurrent clients, and adding some kind of warning or merge rejection when we introduce changes that cause performance to drop dramatically in some scenario.
|
|
|
|
|
|
## BLOBs infrastructure
|
|
|
|
|
|
The pristine version of Soledad used to store all data as JSON documents, which means that binary data was also being treated as strings. This has many drawbacks, as increased memory usage and difficulties to do transfer and crypto in a proper binary pipeline.
|
|
|
|
|
|
Starting with **0.10.0**, Soledad now has a proper BLOB infrastructure that decouples payloads from metadata both in storage and in the synchronization process. The first use case was mail delivery, and we implemented an API so the MX component now hands Soledad Server the responsibility of packing and storing incoming messages as public-key-encrypted data. Metadata is synchronized using the usual sync mechanism, while BLOBs are synchronized in parallel and on-demand. This makes it feasible to have much quicker feedback of incoming messages and load their content and attachments on demand, as is done in most implementations of IMAP clients.
|
|
|
|
|
|
## Client-side transfer/crypto pipeline optimization.
|
|
|
## Server-side backend storage optimization.
|
|
|
## Server scalability. |
|
|
\ No newline at end of file |