Replication of benchmarks in Solr

[nsoft]

I'm looking at trying to replicate some of the benchmarks used here on Solr, and I'm wondering if there's anywhere that documents the fields/options for those fields. I know schema.xml is a Solr thing of course, but predictably I want to write a schema.xml that corresponds to an identical index (or as near to that as possible).

What's the best place in this repo to find that kind of information?

Also the format of the downloaded files (after setup.py) is somewhat interesting. What's the reason that the articles are broken up into many lines rather than sticking all the text on one line? This would seem to complicate processing unless the index being built is producing multiple documents per article?

• Gus

[mikemccand]

Hi @nsoft -- that's a great idea (replicating benchmarks in Solr). Probably the best place to see the "effective" schema is in LineFileDocs, where it creates each document.

[nsoft]

Thanks, that helps, looks like the build.gradle doesn't declare any dependencies which makes IDE's complain about every non JDK class... I'm guessing the scripts pull down dependencies somewhere, any chance you'd be interested in letting gradle do that work so it can also tell IDE's what's what?

[nsoft]

hmm maybe all it needs is the lucene ref? is that the only dependency?

[nsoft]

Ok I hadn't found the build.gradle in the main directory, which is a slightly unexpected location. Nevermind. I think I see what's going on now.

[nsoft]

It's taking quite a while to dig not only the tests out of the code, but what their parameters are. Any reason the tests parameters are not defined declaratively in something like a properties file? That would make it instantly clear how many tests there are and how many variations exist, and exactly how each is set up (rather than having to track down command line parameters, assembled in a python script and then passed into a java program which eventually uses that information to decide an if statement.... to answer a question like "is the body field stored for this test?")

Also it's clear that some things done here really don't apply to Solr (like running single threaded to ensure a set segments config... I don't think that's relevant to how people use Solr).

[mikemccand]

Any reason the tests parameters are not defined declaratively in something like a properties file?

No good reason -- all these tools built organically with time. We do have a tasks file that declares which queries/tasks to run.

Also it's clear that some things done here really don't apply to Solr (like running single threaded to ensure a set segments config... I don't think that's relevant to how people use Solr).

Yeah that's fair -- Solr's benchmarks could simply reflect the segment geometry noise of each Lucene index from the same set of documents over time.