[slightly off topic] Jetty and NIO

[Grant Ingersoll <gs...@apache.org>]

In the Solr example jetty.xml, there is the following setup and  
comments:
<!-- Use this connector for many frequently idle connections
          and for threadless continuations.
     <Call name="addConnector">
       <Arg>
           <New class="org.mortbay.jetty.nio.SelectChannelConnector">
             <Set name="port"><SystemProperty name="jetty.port"  
default="8983"/></Set>
             <Set name="maxIdleTime">30000</Set>
             <Set name="Acceptors">2</Set>
             <Set name="confidentialPort">8443</Set>
           </New>
       </Arg>
     </Call>
    -->

     <!-- Use this connector if NIO is not available. -->
     <!-- This connector is currently being used for Solr because the
          nio.SelectChannelConnector showed poor performance under  
WindowsXP
          from a single client with non-persistent connections (35s vs  
~3min)
          to complete 10,000 requests)
     -->
     <Call name="addConnector">
       <Arg>
           <New class="org.mortbay.jetty.bio.SocketConnector">
             <Set name="port"><SystemProperty name="jetty.port"  
default="8983"/></Set>
             <Set name="maxIdleTime">50000</Set>
             <Set name="lowResourceMaxIdleTime">1500</Set>
           </New>
       </Arg>
     </Call>

So, if I'm on Centos 2.6 (64 bit), what connector should I be using?   
Based on the comments, I'm not sure the top one is the right thing  
either, but it also sounds like it is my only other choice.

The other thing I'm noticing is if I profile my app and I am  
retrieving something like 50 rows at a time, 30-60% of the time is  
spent in org.mortbay.jetty.bio.SocketConnector$Connection.fill().   I  
realize the answer may just be to get less results, but I was  
wondering if there are other tuning parameters that can make this more  
efficient b/c the 50 rows thing is a biz. reqt and I may not be able  
to get that changed.

Thanks,
Grant

Re: [slightly off topic] Jetty and NIO

[Grant Ingersoll <gs...@apache.org>]

On Oct 8, 2009, at 7:37 PM, Yonik Seeley wrote:

> On Thu, Oct 8, 2009 at 6:24 PM, Grant Ingersoll  
> <gs...@apache.org> wrote:
>> So, if I'm on Centos 2.6 (64 bit), what connector should I be  
>> using?  Based
>> on the comments, I'm not sure the top one is the right thing  
>> either, but it
>> also sounds like it is my only other choice.
>
> Right - the connector that Solr uses in the example is fine for
> typical Solr uses - NIO won't help.
>
>> The other thing I'm noticing is if I profile my app and I am  
>> retrieving
>> something like 50 rows at a time, 30-60% of the time is spent in
>> org.mortbay.jetty.bio.SocketConnector$Connection.fill().
>
> On the Solr server side?

Yes.

> That's code that *reads* a request from the
> client...

If I change nothing else and set rows=10, the time spent in .fill() is  
< 5%.  I'll double check everything on my end.


> so if a lot of time is being spent there, it's probably
> blocking waiting for the rest of the request?  The tests could be
> network bound, or the test client may not be fast enough?
>
> If we are saturating the network connection, then use SolrJ if you're
> not, w/ the binary response format, or use something like JSON format
> otherwise.  If you end up using a text response format, you could try
> enabling compression for responses (not sure how with jetty).

Re: [slightly off topic] Jetty and NIO

[Yonik Seeley <yo...@lucidimagination.com>]

On Thu, Oct 8, 2009 at 6:24 PM, Grant Ingersoll <gs...@apache.org> wrote:
> So, if I'm on Centos 2.6 (64 bit), what connector should I be using?  Based
> on the comments, I'm not sure the top one is the right thing either, but it
> also sounds like it is my only other choice.

Right - the connector that Solr uses in the example is fine for
typical Solr uses - NIO won't help.

> The other thing I'm noticing is if I profile my app and I am retrieving
> something like 50 rows at a time, 30-60% of the time is spent in
> org.mortbay.jetty.bio.SocketConnector$Connection.fill().

On the Solr server side?  That's code that *reads* a request from the
client... so if a lot of time is being spent there, it's probably
blocking waiting for the rest of the request?  The tests could be
network bound, or the test client may not be fast enough?

If we are saturating the network connection, then use SolrJ if you're
not, w/ the binary response format, or use something like JSON format
otherwise.  If you end up using a text response format, you could try
enabling compression for responses (not sure how with jetty).

-Yonik
http://www.lucidimagination.com

>   I realize the
> answer may just be to get less results, but I was wondering if there are
> other tuning parameters that can make this more efficient b/c the 50 rows
> thing is a biz. reqt and I may not be able to get that changed.
>
> Thanks,
> Grant
>