[ 
https://issues.apache.org/jira/browse/SOLR-829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646478#action_12646478
 ] 

shalinmangar edited comment on SOLR-829 at 11/10/08 9:45 PM:
----------------------------------------------------------------------

Thanks Akshay

Hoss, do you know of a GzipServlet which we can borrow? Until that is in place, 
we can probably go ahead with this patch. Anyway, the configuration will not 
change, only the internal implementation needs to change (client sending 
Accept-Encoding in place of zip=true)

      was (Author: shalinmangar):
    Thanks Akshay

Hoss, do you know of a GzipServlet which we can borrow? Until that is in place, 
we can probably go ahead with this patch. Anyway, only the configuration will 
not change, only the internal implementation needs to change (client sending 
Accept-Encoding in place of zip=true)
  
> replication Compression
> -----------------------
>
>                 Key: SOLR-829
>                 URL: https://issues.apache.org/jira/browse/SOLR-829
>             Project: Solr
>          Issue Type: Improvement
>          Components: replication (java)
>            Reporter: Simon Collins
>            Assignee: Shalin Shekhar Mangar
>         Attachments: email discussion.txt, solr-829.patch
>
>
> From a discussion on the mailing list solr-user, it would be useful to have 
> an option to compress the files sent between servers for replication purposes.
> Files sent across between indexes can be compressed by a large margin 
> allowing for easier replication between sites.
> ...Noted by Noble Paul 
> we will use a gzip on both ends of the pipe . On the slave side you can say 
> <str name="zip">true<str> as an extra option to compress and send data from 
> server 
> Other thoughts on issue: 
> Do keep in mind that compression is a CPU intensive process so it is a trade 
> off between CPU utilization and network bandwidth.  I have see cases where 
> compressing the data before a network transfer ended up being slower than 
> without compression because the cost of compression and un-compression was 
> more than the gain in network transfer.
> Why invent something when compression is standard in HTTP? --wunder

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to