On 3/24/2018 6:21 PM, Deepak Goel wrote:
Do you have any documented proof of the same (1 to 5ms)? Or is it an educated guess
Just now, I did a test. I did a "*:*" query (all docs), the QTime was 194 milliseconds, numFound was 188635489. Then I did the exact same query again. QTime dropped to 39 milliseconds.
Next, I did a query for "banjo" ... something I don't think a lot of people are searching for. The QTime on this was 2395 milliseconds, numFound was 737280. Running the same query again, QTime dropped to 11 milliseconds.
My index is big and distributed. Your index is very small, and likely contained in one core, so it should have far better performance than my index.
I dont think Tomcat and Jmeter are a bottleneck. But I will bump up the heap size of them too
I was actually thinking that if these are run *without* a max heap setting, that you might want to explicitly set the heap size so that it's not too big. Those programs probably don't need a very big heap at all. If Java were to choose a big default heap size, the server might start swapping, and that would REALLY make performance bad, especially on Windows.
The problem I am facing: On Windows, the tps is 28 while on Linix, the tps is 564 (All the configuration and hardware is same). The other problem is, Even if there is plenty of hardware available, the Windows environment does not scale. And I wonder why is this so?
My first guess would be the 512MB heap, possibly causing even more problems on Windows.
And then there's my general bias against Microsoft. I have witnessed deficiencies in their memory management, their filesystem performance, and other things. Linux just does a better job in almost every category that I care about for a server.
Which version of Windows are you running it on? You would only want to do a test like this on a Server OS, and I'd hope that it's at least Server 2008. The client operating systems do not handle server programs very well. And it should be a 64-bit OS, with 64-bit Java.
Thanks, Shawn
