I/O buffering would certainly be handled by the OS but in theory the application can do its own buffering -and in a sense RAMDirectory is an extreme example of this. Having an app w/ an adjustable buffer pool gives you more options for tuning.
-----Original Message----- From: Jonathan Pace [mailto:jmpace@;fedex.com] Sent: Thursday, October 17, 2002 10:54 AM To: Lucene Users List Subject: RE: Using Pooled IndexSearchers? The index is only a gig, but of course, optimizing will increase that size substantially. At the rate our index grows, it would be better to keep it in a disk array. I assume that I/O buffering would be handled by the underlying OS wouldn't it? -jon -----Original Message----- From: Spencer, Dave [mailto:dave@;lumos.com] Sent: Thursday, October 17, 2002 11:45 AM To: Lucene Users List Subject: RE: Using Pooled IndexSearchers? One idea - have you tried searching with a RAMDirectory instead of an FSDirectory? If you index fits into memory then this could be a win. Some notes & code here: http://www.tropo.com/techno/java/lucene/rammer.html Note: I know some people have huge indexes that "can't" fit into RAM...but I'm sure I've read that Google uses solid state ("ram") disks in their search farm. Can't find the article however that says this. Might have been an interview w/ E. Schmidt. Also: does Lucene have any buffer control in the API? In theory shouldn't IndexSearcher, or FSDirectory, have control over buffering of disk blocks? -----Original Message----- From: Jonathan Pace [mailto:jmpace@;fedex.com] Sent: Thursday, October 17, 2002 8:08 AM To: Lucene Users List Subject: Using Pooled IndexSearchers? Just a question for the group. Is anyone using or have benchmarked a pooled IndexSearcher setup? (Especially the Jakarta Commons POOL implementations) I am looking to increase the concurrent search performance because quite a few of our users use DateFiltering which dramatically increases search times. Is it worth the effort? Thankyou in advance. Jonathan M Pace Sr Programmer/Analyst Corporate Portal Development FedEx Services 60 FedEx Pkwy 1st Floor Horiz 901-263-4744 [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:lucene-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:lucene-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:lucene-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:lucene-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:lucene-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:lucene-user-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:lucene-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:lucene-user-help@;jakarta.apache.org>
