Its been months since i've tested this sort of thing, but from what I remember there is a point where as you go higher, performance starts to very slowly drop. The point was lower than I'd expect, and def created what looked like sweet spot settings.
On Wed, 2008-05-14 at 18:36 -0700, Otis Gospodnetic wrote: > Karl, which caches are you referring to? Things like maxBufferedDocs and the > recent memory-based in-memory buffer? If so, isn't "the bigger the better" > the answer? > > > Otis > -- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > ----- Original Message ---- > > From: Karl Wettin <[EMAIL PROTECTED]> > > To: java-user@lucene.apache.org > > Sent: Wednesday, May 14, 2008 7:41:08 PM > > Subject: IndexWriter cache swetspots > > > > I have an index with several million documents that each contains > > between a few hundred terms and up to about a million terms. To me it > > feels like there would be a rather big difference between the swetspot > > setting for the cache size when adding very large and very small > > documents. > > > > What are the other factors I have to consider when benchmarking this? > > Number of threads? Initial index size? > > > > > > The things is that I don't know what good the cache does in the first > > place nor what it does. Perhaps this is all in vain, but I'm sort of > > hoping it's possible to automatically find and set the cache sweetspot > > by sampling miscellaneous data in realtime. > > > > Does this make sense? > > > > > > karl > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
