Reduced java/tomcat performance 6-beta3 -> 6-stable ?

[Eirik Øverby]

On Dec 1, 2005, at 04:12 , Michael Vince wrote:

> Some apps that use of frequent queries of the system time for  
> example MySQL are well known in FreeBSD to be slower then Linux  
> because its  more expensive to call compared to Linux, maybe Tomcat  
> is also another such app this can also be double the case depending  
> on on your jsp and servlet code.

True, but on equal hardware it should perform equally.

> If you are on good hardware, are using 6 and keep your systems time  
> updated via ntp you might want to try changing from  
> kern.timecounter.hardware: ACPI-fast to TSC(-100) and doing a  
> benchmark this has already proven to increase performance of MySQL  
> by a significantly amount.

I will try this, though it will not solve my original problem (and  
the subject is somewhat misleading now, as this seems to be  
independent of kernel revisions).

> Also some new experimental low-precision time code has been added  
> to current source tree to see how much performance increases can be  
> gained, weirdly enough some people have argued against it for I  
> guess a wide range of reasons such as they just have crap hardware  
> and don't care about performance, don't like the extra maintenance  
> of code or just like Red Hat fanatics having an easy way to bad  
> mouth FreeBSD performance. I think most people would agree though  
> that it has to be done, or have to choose to believe FreeBSD isn't  
> about performance among other goals.

I will not join this discussion ;)

> With 6 you can also use the new thr threading library, try your  
> libmap.conf to libthr for testing, for example
> [/usr/local/jdk1.4.2/]
> libpthread.so.2         libthr.so.2
> libpthread.so           libthr.so
>
> I been doing some 'ab' testing libthr with Apache2 compiled for  
> worker MPM and have some really interesting differences on server  
> load, loads of about 40 for pthread and around 5 thr under certain  
> tests with ab with the exact same test.

Too bad this causes jdk1.5.0-amd64 to crash...
Application startup times were significantly reduced, but only the  
times it actually managed to start without failing. Latest at the 2nd  
or 3rd transaction Java coredumps. :(

And as current load testing is done without Apache in between, this  
is moot..

/Eirik


>
> Mike
>
>
> Eirik Øverby wrote:
>
>> Update: The diff below was made after making sure both systems  
>> are  running the exact same kernel. Behavior is the same. Building  
>> new  kernels (6-STABLE) now to get out of the BETA stage.
>>
>> /Eirik
>>
>> On Nov 28, 2005, at 22:53 , Eirik Øverby wrote:
>>
>>> Firmware versions are equal. BIOS settings are equal.
>>> However, a diff of the dmesgs show (apart from MAC address   
>>> differences):
>>>
>>> 30c30
>>> < Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000
>>> ---
>>> > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
>>>
>>> What on earth is that all about? The "slow" box has the ACPI- 
>>> fast  timecounter...
>>>
>>> /Eirik
>>>
>>> On Nov 28, 2005, at 22:14 , Kris Kennaway wrote:
>>>
>>>> On Mon, Nov 28, 2005 at 09:54:30PM +0100, Eirik ?verby wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I think I have found the culprit. There must be some sort of
>>>>> difference between the machines after all (BIOS revision?),  
>>>>> because
>>>>> while on one machine the interrupt rate for the bge card stays  
>>>>> very
>>>>> low (2 to be exact) during maximum load, the other machine goes
>>>>> beyond 1000 and keeps rising constantly. This might also  
>>>>> explain why
>>>>> performance slowly degrades over time on that machine, and  
>>>>> response
>>>>> times vary wildly, while the "fast" machine responds nicely within
>>>>> 1-2 seconds no matter the load and testing time.
>>>>>
>>>>> I will have to investigate this more closely. Is there a way  
>>>>> to  force
>>>>> the NIC to polling mode (I'm assuming that is the difference,  
>>>>> an IRQ
>>>>> rate of 2 is too low for a heavily loaded server if the NIC is
>>>>> interrupt-driven)?
>>>>>
>>>>> Anything else I could look at?
>>>>
>>>>
>>>> BIOS update.
>>>>
>>>> Kris
>>>
>>>
>>
>
>
>