Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: feature-backlog
    • Component/s: XDCR
    • Security Level: Public
    • Labels:
      None

      Description

      As XDCR will almost always be used across an internet/WAN link, doing all we can to reduce the bandwidth will be critical. Given that the data is already compressed on disk, couldn't it be sent that way and uncompressed on the destination side?

      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        Hide
        junyi Junyi Xie (Inactive) added a comment -

        Today in XDCR we use base64 encoding of all user-data and transmit them over internet/WAM link, we batch and package, but do not compress them within XDCR at this time. If the document size is huge, it may make some sense to compress them to save some bandwidth. But today, from Performance and QE team, mostly the the document is around several k bytes, the batch created by XDCR is at most 2M bytes by default. Given the overhead of compression and decompression, I am not sure how much benefit to compress them.

        Show
        junyi Junyi Xie (Inactive) added a comment - Today in XDCR we use base64 encoding of all user-data and transmit them over internet/WAM link, we batch and package, but do not compress them within XDCR at this time. If the document size is huge, it may make some sense to compress them to save some bandwidth. But today, from Performance and QE team, mostly the the document is around several k bytes, the batch created by XDCR is at most 2M bytes by default. Given the overhead of compression and decompression, I am not sure how much benefit to compress them.
        Hide
        perry Perry Krug added a comment -

        To be clear, the benefit is not for performance but for saving network bandwidth on customer links that they will very likely have to pay for each bit they transfer.

        Show
        perry Perry Krug added a comment - To be clear, the benefit is not for performance but for saving network bandwidth on customer links that they will very likely have to pay for each bit they transfer.
        Hide
        junyi Junyi Xie (Inactive) added a comment -

        In 2.0.2, we will introduce "optimistic XDCR" which allows users to continuously tune XDCR performance in the range between favoring bandwidth and favoring latency. Given this new feature and to prioritize tasks, IMHO at this time it is not very urgent to compress the XDCR traffic to save bandwidth, therefore I tentatively mark the fix version as 2.1.

        Show
        junyi Junyi Xie (Inactive) added a comment - In 2.0.2, we will introduce "optimistic XDCR" which allows users to continuously tune XDCR performance in the range between favoring bandwidth and favoring latency. Given this new feature and to prioritize tasks, IMHO at this time it is not very urgent to compress the XDCR traffic to save bandwidth, therefore I tentatively mark the fix version as 2.1.

          People

          • Assignee:
            anil Anil Kumar
            Reporter:
            perry Perry Krug
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:

              Gerrit Reviews

              There are no open Gerrit changes