On 9/12/2013 12:55 PM, phanichaitanya wrote:
> I want to make sure that documents that are indexed are committed in say an
> hour. I agree that if you pass commitWithIn params and the like will make
> sure of that based on the time configurations we set. But, I want to make
> sure that the document is really committed within whatever time we set using
> commitWithIn.
> 
> It's a question asking for proof that Solr commits within that time if we
> add commitWithIn parameter to the configuration.
> 
> That is about commitWithIn parameter option that you suggested.
> 
> Now is there a way to explicitly get all the documents that are committed
> when a hard commit request is issued ? This might not make sense but we are
> pondered with that question.

If these are ongoing requirements that you need to with every commit or
with a large subset of commits, then I don't think there is any way to
do it without writing custom plugins for Solr.

If you are just trying to prove to someone that Solr is doing what you
say it is, then you can do some simple testing:

Send an update request with as many documents as you want to test, and
include commit=true on the request.  If you are planning to use
commitWithin, also include SoftCommit=true, because commitWithin is a
soft commit.

Time how long it takes for the update request to complete.  That's
approximately how long it will take for a "real" update/commit to
happen.  There will be some extra time for the indexing itself, but
unless the document count is absolutely enormous, it shouldn't matter
too much.

If you want to test just the commit time, then (after making sure
nothing else is sending updates or commits) send the update without any
commit parameters, then send a commit request by itself and time how
long the commit request takes.

With enough RAM for proper OS disk caching, commits should be very fast
even on an index with 10 million documents.  Here is a wiki page that
has a small amount of discussion about slow commits:

http://wiki.apache.org/solr/SolrPerformanceProblems#Slow_commits

Thanks,
Shawn

Reply via email to