lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: Benchmarking Solr 3.3 vs. 4.0
Date Thu, 29 Nov 2012 14:30:34 GMT
On 11/29/2012 3:15 AM, Daniel Exner wrote:
> I'm currently doing some benchmarking of a real Solr 3.3 instance vs 
> the same ported to Solr 4.0.
> Benchmarking is done using JMeter from localhost.
> Test scenario is a constant stream of queries from a log file out of 
> production, at targeted 50 QPS.
> After some time (marked in graph) I do a push via REST interface of 
> the whole index data (796M XML), wait some time and do a optimize via 
> Testmachine is a VM on a "Intel(R) Core(TM)2 Quad CPU Q9400 @2.66GH", 
> one core and 2Gb RAM attached.
> Both Solr instances are running in the same Tomcat and are not used 
> otherwise than testing.
> Expected results where a lower overall load for Solr 4 and a lower 
> latency while pushing new data.
> In the graph you can see high CPU load, all the time. This is even the 
> case if I reduce the QPS down to 5, so CPU is no good metric for 
> comparison between Solr 3.3 and 4.0 (at least on this machine).
> The missing memory data is due to the PerfMon JMeter Plugin having 
> time-outs sometimes.
> You can also see no real increase in latency when pushing data into 
> the index. This is puzzling me, as rumours say one should not push new 
> data while under high load, as this would hurt query performance.

I don't see any attachments, or any links to external attachments, so I 
can't see the graph.  I can only make general statements, and I can't 
guarantee that they'll even be applicable to your scenario.  You may 
need to use an external attachment service and just send us a link.

Are you seeing lower performance, or just worried about the CPU load?  
Solr4 should be able to handle concurrent indexing and querying better 
than 3.x.  It is able to do things concurrently that were not possible 

One way that performance improvements happen is that developers find 
slow sections of code where the CPU is fairly idle, and rewrite them so 
they are faster, but also exercise the CPU harder.  When the new code 
runs, CPU load goes higher, but it all runs faster.


View raw message