lucene-ruby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <e...@ehatchersolutions.com>
Subject Re: quick jruby + solr benchmarks
Date Wed, 26 Nov 2008 15:10:15 GMT
On Nov 26, 2008, at 9:54 AM, Matt Mitchell wrote:
> Yeah I overlooked all of that. Thanks Erik. So could a better query  
> test be
> an incremental one based on id like:
>
> 100.times do |id|
>  q = "id:#{id}"
>  # query request here...
> end
>
> ?

Testing is an art form.  Depends on what you are testing.  Issuing  
entirely unique queries is not very real-world either, but at least it  
will cause the bypassing of query and HTTP caching shortcuts.

Many organizations mine their query logs to get a set of  
representative queries to test with, for example.

I think your point is proven - EmbeddedSolrServer itself is faster  
than CommonsHttpSolrServer.  But would you deploy that way?  Is your  
front-end going to be merged with Solr itself?  That may or may not be  
very viable, depending on the resources the front-end and Solr needs  
and how much system resources you have.  What about doing load  
balancing?  You're then stuck with load balancing your front-end in  
tandem with Solr itself.

Again, it all boils down to what you're after with the benchmarks.   
And I'm not a benchmarking performance savvy person myself, so I'm not  
sure where to take it from here.  It's an interesting test, for sure,  
and I'd like to have it reviewed by others that really know their  
stuff in this realm and with Solr itself that can elaborate on why  
there is such a huge difference in speed.  Is it just HTTP and  
serialize/unserialize overhead?  (I tend to doubt that, but don't know)

> Would you happen to know why the solr home and data dir never really  
> change?
> Anytime I use commons http or embedded, a "solr" directory is  
> created in the
> same directory as my script. Even though I'm setting the home and  
> data dir
> in my code?

I don't know at the moment, I'd have to dig deeper.

	Erik


Mime
View raw message