From everything you've said, it certainly sounds like a low-level I/O
problem in the client, not a server slowdown of any sort. Maybe Perl is
using the same connection over and over (keep-alive) and Java is not. I
really don't know. One thing I've heard is that
StreamingUpdateSolrServer (I think that's what it's called) can give
better throughput for large request batches. If you're not using that,
you may be having problems w/closing and re-opening connections?
-Mike
On 10/26/2011 9:56 PM, Shawn Heisey wrote:
On 10/26/2011 6:16 PM, Michael Sokolov wrote:
Have you checked to see when you are committing? Is the pattern the
same in both instances? If you are committing after each delete
request in Java, but not in Perl, that could slow things down.
Due to the multihreading of delete requests, I now have the full
delete down to 10-15 seconds instead of a minute or more. This is now
an acceptable time, but I am completely mystified as to why the Pelr
code can do it without multithreading just as fast, and often faster.
The Java code is long-running, and the Perl code is started by cron.
If you look back to the first message on the thread, you'll see commit
messages in the Perl log, but those commits are done with the wait
options set to false. That's an extra step the Java code isn't doing
- and it's STILL faster.
