lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "S├ębastien Rainville" <sebastienrainvi...@gmail.com>
Subject Re: Solr performance issues
Date Fri, 20 Jun 2008 13:36:49 GMT
On Fri, Jun 20, 2008 at 8:32 AM, Erik Hatcher <erik@ehatchersolutions.com>
wrote:

>
> On Jun 19, 2008, at 6:28 PM, Yonik Seeley wrote:
>
>> 2. I use acts_as_solr and by default they only make "post" requests, even
>>> for /select. With that setup the response time for most queries, simple
>>> or
>>> complex ones, were ranging from 150ms to 600ms, with an average of 250ms.
>>> I
>>> changed the select request to use "get" requests instead and now the
>>> response time is down to 10ms to 60ms. Did someone seen that before? Why
>>> is
>>> it doing it?
>>>
>>
>> Are the get requests being cached by the ruby stuff?
>>
>
> No, I'm sure that the results aren't being cached by Ruby's library,
> solr-ruby, or acts_as_solr.
>

I confirm that the results are not cached by Ruby's library.


But even with no caching, I've seen differences with get/post on Linux
>> with the python client when persistent HTTP connections were in use.
>> I tracked it down to the POST being written in two parts, triggering
>> nagle's algorithm in the networking stack.
>>
>
> There was another post I found that mentioned this a couple of years ago:
>
> <http://markmail.org/message/45qflvwnakhripqp>
>
> I would welcome patches with tests that allow solr-ruby to send most
> requests with GET, and the ones that are actually sending a body beyond just
> parameters (delete, update, commit) as POST.
>
>        Erik
>
>
I made a few modifications but it still need more testing...

Sebastien

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message