[
https://issues.apache.org/jira/browse/SOLR-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561035#action_12561035
]
Sean Timm commented on SOLR-462:
--------------------------------
There are two reasons I chose to not have compression enabled by default: (1)
it seems like most Solr deployments use Tomcat or Jetty stand-alone--to get
compression, you need to either use a servlet filter to do the compression or
put the servlet container behind Apache or another web server enabled to
provide the compression, and (2) if both the Solr servers and the Solrj clients
are on the same local network, with a 100 Mbps or even gigabit connection, is
the CPU overhead of compression going to buy you enough on the IO side? Now if
you have Solr in one data center and your Solrj in a different data center,
compression is likely a benefit. The option is nice and it is a quick thing to
try to see if it helps in your particular circumstance.
> Performance related enhancements to Solrj
> -----------------------------------------
>
> Key: SOLR-462
> URL: https://issues.apache.org/jira/browse/SOLR-462
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
> Reporter: Sean Timm
> Assignee: Ryan McKinley
> Fix For: 1.3
>
> Attachments: solrj-SOLR-462.patch
>
>
> Changes to CommonsHttpSolrServer.java to add soTimeout (read timeout),
> connection pool timeout, directive to not follow HTTP redirects, configurable
> retries on NoHttpResponseException, compression, and not creating a new
> HttpClient on each request.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
