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.

Reply via email to