[
https://issues.apache.org/jira/browse/SOLR-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12678712#action_12678712
]
noble.paul edited comment on SOLR-1044 at 3/4/09 7:51 PM:
----------------------------------------------------------
Hadoop RPC looks bad in my initial studies for a packet size of 2048 bytes.
tests run with 5 client threads , over 20 secs
{code}
hadoop RPC: 3036 req/sec . average latency 1.6ms
tomcat: 82012 4100/s average latency 1.ms
{code}
this may not be an apple to apple comparison. Here tomcat uses 5 connections
internally and hadoop RPC uses only one. But , this is a more realistic one
because we have no framework which can cache and reuse connections like
httpclient
was (Author: noble.paul):
Hadoop RPC looks bad in my initial studies for a packet size of 2048
bytes. tests run with 5 client threads , over 20 secs
{code}
hadoop RPC: 3036 req/sec . average latency 1.6ms
tomcat: 82012 4100/s average latency 1.ms
{code}
> Use Hadoop RPC for inter Solr communication
> -------------------------------------------
>
> Key: SOLR-1044
> URL: https://issues.apache.org/jira/browse/SOLR-1044
> Project: Solr
> Issue Type: New Feature
> Components: search
> Reporter: Noble Paul
>
> Solr uses http for distributed search . We can make it a whole lot faster if
> we use an RPC mechanism which is more lightweight/efficient.
> Hadoop RPC looks like a good candidate for this.
> The implementation should just have one protocol. It should follow the Solr's
> idiom of making remote calls . A uri + params +[optional stream(s)] . The
> response can be a stream of bytes.
> To make this work we must make the SolrServer implementation pluggable in
> distributed search. Users should be able to choose between the current
> CommonshttpSolrServer, or a HadoopRpcSolrServer .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
