Over a million developers have joined DZone.

Searching Out Performance for Apache Solr

DZone's Guide to

Searching Out Performance for Apache Solr

We decided to compare the performance of Solr running on Zing using C4 to Oracle’s Hotspot JVM using G1 for garbage collection. These are the results.

· Performance Zone ·
Free Resource

SignalFx is the only real-time cloud monitoring platform for infrastructure, microservices, and applications. The platform collects metrics and traces across every component in your cloud environment, replacing traditional point tools with a single integrated solution that works across the stack.

According to the DB-Engines websiteApache Solr is the second most popular search engine software in use today. Since Solr is written in Java, performance will obviously be impacted by which JVM you use.

Recently, here at Azul, we decided to compare the performance of Solr running on Zing using C4 to Oracle’s Hotspot JVM using G1 for garbage collection. To do this, we worked with one of our customers who runs Solr on 200 production nodes. They also use a good size data set of 20Tb, which would provide a realistic comparison between the two JVMs. 

To make things fair, the tests were run on paired workloads using identical configurations. The configurations were:

  1. Full-text search on a machine with 32Gb RAM configured for a 16Gb JVM heap.
  2. Metadata search on a machine with 8Gb RAM configured for a 4Gb JVM heap.

As I’ve said before, people sometimes think that because Zing can scale all the way up to a heap of 2Tb that it must need bigger heaps to work efficiently. This is definitely not the case; using a 4Gb heap for the second set of tests is certainly not big by today’s standards. 

The tests being run were not artificially created benchmarks, but an evaluation of how a real production system works. You can’t really get a better test scenario than that when evaluating performance. 

Again, to ensure fairness and to eliminate any short-term effects on the systems, they were both run for 48 hours. We wanted to make sure that we would see any long-term trends in our data.

To assess the performance of each JVM, we used jHiccup to measure the latency associated with the JVM whilst running the tests. jHiccup is a great tool for this because it runs in the same JVM running the code under test but does not interact directly with the application code. Because we’re running the same application code on identical hardware, any differences in observed latency come purely down to differences in the way the JVMs work internally. You can find out more information about jHiccup here.

I don’t think it’s an understatement to say that the results were conclusive that Zing performs significantly better in this scenario. The graphs that follow show the latency associated with Hotspot using the G1 garbage collector on the left and Zing using the C4 collector on the right.

For the full-text tests, we get these results:

full text search results graph 

The maximum pause time for Oracle’s JVM was 1667ms, and for Zing, it was 67ms. Even taking out most of the outliers from Hotspot (and why would you since this will impact your performance), it’s clear from the graph that Hotspot’s latency is consistently averaging about 250ms.  

With the scale of the graph it’s hard to tell for Zing, so let’s look at the graph scaled to the values recorded.

full text Zing only results graph

Doing this, we can see that Zing is averaging something like 15-20ms.

For the second metadata search test, we get these results:

metadata search results graph In this case, the maximum pause for Hotspot was a massive 184,684ms (that’s over three minutes!) compared to Zing with a maximum pause of 107ms.

Again, scaling the Zing graph to see the data more clearly, we get this.

metadata search Zing results graph

It’s said a picture is worth a thousand words and I think these graphs really speak for themselves.

SignalFx is built on a massively scalable streaming architecture that applies advanced predictive analytics for real-time problem detection. With its NoSample™ distributed tracing capabilities, SignalFx reliably monitors all transactions across microservices, accurately identifying all anomalies. And through data-science-powered directed troubleshooting SignalFx guides the operator to find the root cause of issues in seconds.

performance ,apache solr ,garbage collection ,jvm ,latency

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}