[
https://issues.apache.org/jira/browse/SLING-7362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16318142#comment-16318142
]
Timothee Maret edited comment on SLING-7362 at 1/9/18 10:00 AM:
----------------------------------------------------------------
Thanks [~diru], I have resolved the issue as WON'T DO.
JCRVLT-259 makes sense IMO, but it has a broader scope than tweaking a specific
compression algorithm.
AFAIK, there are attempts (in Sling code base) to provide better serialisation
(better throughput, less space) with Apache Avro and Kryo.
AFAIK, those modules remove the dependency on FileVault entirely. Removing the
FileVault dependency while keeping backward compatibility seems tricky and
quite some effort to me.
Indeed, FileVault has some tweaks that would need to be reproduced precisely in
a new module, in order to keep the expected behaviour.
Thus I really like the JCRVLT-259 approach since it has the potential to keep
the FileVault behaviour, but increase its throughput.
Regarding distribution throughput, we had identified the
serialisation/deserialisation as the "current" main bottleneck in typical AEM
scenarios and thus the first one to tackle. The previous main bottleneck was
JCRVLT-50.
When I started to work on SCD, I also thought that storing the packages to disk
was likely a huge bottleneck. Thus I had opened SLING-5991. But back then we
noticed it was not worth improving that aspect (with the added complexity)
since it had only minor impact on the throughput. Since we have now improved
other performance related aspects, we may revisit SLING-5991 to see if it makes
sense now.
Regarding storing the package once built, AFAIK it is required un order to
guarantee the distribution of packages (not lose distribution request). If
storing the package turns out to be a bottleneck, the SCD code base already
contains an implementation storing packages on the File System rather than the
repository, as well as an implementation that stores the packages in memory
(and thus breaks the aforementioned contract).
[~teofili] may have more details regarding the design.
was (Author: marett):
Thanks [~diru], I have resolved the issue as WON'T DO.
JCRVLT-259 makes sense IMO, but it has a broader scope than tweaking a specific
compression algorithm.
AFAIK, there are attempts (in Sling code base) to provide better serialisation
(better throughput, less space) with Apache Avro and Kryo.
AFAIK, those modules remove the dependency on FileVault entirely. Removing the
FileVault dependency while keeping backward compatibility seems tricky and
quite some effort to me.
Indeed, FileVault has some tweaks that would need to be reproduced precisely in
a new module, in order to keep the expected behaviour.
Thus I really like the JCRVLT-259 approach since it has the potential to keep
the FileVault behaviour, but increase its throughput.
Regarding distribution throughput, we had identified the
serialisation/deserialisation as the "current" main bottleneck in typical AEM
scenarios and thus the first one to tackle. The previous main bottleneck was
JCRVLT-50.
Regarding storing the package once built, AFAIK it is required un order to
guarantee the distribution of packages (not lose distribution request). If
storing the package turns out to be a bottleneck, the SCD code base already
contains an implementation storing packages on the File System rather than the
repository, as well as an implementation that stores the packages in memory
(and thus breaks the aforementioned contract).
[~teofili] may have more details regarding the design.
> Allow to configure the SCD default compression level
> ----------------------------------------------------
>
> Key: SLING-7362
> URL: https://issues.apache.org/jira/browse/SLING-7362
> Project: Sling
> Issue Type: Improvement
> Components: Content Distribution
> Reporter: Timothee Maret
> Assignee: Timothee Maret
> Fix For: Content Distribution Core 0.2.12
>
>
> In some scenarios, such as the one reported in JCRVLT-257 (essentially an
> issue in zlib), it makes sense to allow specifying the default compression
> level.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
