ing 95% of HugePages benefits without
LargePages penalties (heap locking/pinning and app specific config). So
users of virtualisation, databases and JVMs with large heaps can rejoice :)
--
View this message in context:
http://old.nabble.com/Performance-for-many-small-requests-tp32372424p323938
> -Original Message-
> From: Darius D. [mailto:darius@gmail.com]
> Sent: Saturday, September 03, 2011 1:36 PM
>
> As a side note - (CPU)cache/TLB misses have nothing to do with heap size.
> Too big heap size can be as bad as too low ( by stealing memory from OS that
> could
> have bee
> From: David Kerber [mailto:dcker...@verizon.net]
> Subject: Re: Performance for many small requests
> Then why shouldn't I just double my heap size? Wouldn't
> that eliminate the risk of increased cache misses?
As Darius stated, this part of the discussion is probably
David Kerber wrote:
>
> On 9/3/2011 1:15 PM, Darius D. wrote:
>>
>>
>> n828cl wrote:
>>>> From: Darius D. [mailto:darius@gmail.com]
>>>> Subject: Re: Performance for many small requests
>>>> in my opinion using 64bit JVM with
On 9/3/2011 1:15 PM, Darius D. wrote:
n828cl wrote:
From: Darius D. [mailto:darius@gmail.com]
Subject: Re: Performance for many small requests
in my opinion using 64bit JVM with such a small
heap is only needed if performance testing shows
gains versus 32bit JVM.
The main advantage of
n828cl wrote:
>
>> From: Darius D. [mailto:darius@gmail.com]
>> Subject: Re: Performance for many small requests
>
>> in my opinion using 64bit JVM with such a small
>> heap is only needed if performance testing shows
>> gains versus 32bit JVM.
>
> From: Darius D. [mailto:darius@gmail.com]
> Subject: Re: Performance for many small requests
> in my opinion using 64bit JVM with such a small
> heap is only needed if performance testing shows
> gains versus 32bit JVM.
The main advantage of using a 64-bit JVM is the incr
isses. -XX:+UseCompressedOops can help to
remove some of this tax, but in my opinion using 64bit JVM with such a small
heap is only needed if performance testing shows gains versus 32bit JVM.
--
View this message in context:
http://old.nabble.com/Performance-for-many-small-requests-tp32372424p323
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
On 9/1/2011 4:52 PM, Caldarale, Charles R wrote:
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Subject: Re: Performance for many small requests
>
>>> NIO may incur slightly more overhead
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Subject: Re: Performance for many small requests
> > NIO may incur slightly more overhead due to thread switching.
> > You'll have to measure to see if it's of any benefit.
> Yes, but my guess
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
On 9/1/2011 2:00 PM, Caldarale, Charles R wrote:
>> From: David kerber [mailto:dcker...@verizon.net] Subject: Re:
>> Performance for many small requests
>
>>> You could also use the NIO connector which allows you t
> From: David kerber [mailto:dcker...@verizon.net]
> Subject: Re: Performance for many small requests
> > You could also use the NIO connector which allows you
> > to have fewer threads serve more requests without the
> > keepalive-expiration delay.
> Thanks, I&#
On 9/1/2011 1:15 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David,
On 9/1/2011 10:40 AM, David kerber wrote:
I'm having some somewhat minor performance issues, not performing
quite as well as my Win2k machine with TC 5.5. Could somebody look
at my server.xml
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David,
On 9/1/2011 10:40 AM, David kerber wrote:
> I'm having some somewhat minor performance issues, not performing
> quite as well as my Win2k machine with TC 5.5. Could somebody look
> at my server.xml and recommend some tweaks for handling tons o
> From: David kerber [mailto:dcker...@verizon.net]
> Subject: Re: Performance for many small requests
> > For small requests having a large new generation in the heap helps.
> > This helps with the short term objects in the heap to get collected.
> I'm not sure what th
s round of performance tuning a couple of
years ago.
Hope this helps.
-Tony
--- On Thu, 9/1/11, Caldarale, Charles R wrote:
From: Caldarale, Charles R
Subject: RE: Performance for many small requests
To: "Tomcat Users List"
Date: Thursday, September 1, 2011, 9:58 AM
From: David
and has to wait for disk IO unless it is spawned off to an independent thread.
Hope this helps.
-Tony
--- On Thu, 9/1/11, Caldarale, Charles R wrote:
> From: Caldarale, Charles R
> Subject: RE: Performance for many small requests
> To: "Tomcat Users List"
> Date: Thurs
> From: David kerber [mailto:dcker...@verizon.net]
> Subject: Re: Performance for many small requests
> Is there any indication from what I've said that
> I need a larger heap?
Don't think so, but GC logging will tell you for sure. The compressed OOPs
capability with a
On 9/1/2011 11:36 AM, Caldarale, Charles R wrote:
From: David kerber [mailto:dcker...@verizon.net]
Subject: Re: Performance for many small requests
Are you using 64-bit java or 32-bit?
64-bit.
Might want to try -XX:+UseCompressedOops, since you have a small heap on a
64-bit JVM.
I&#x
> From: David kerber [mailto:dcker...@verizon.net]
> Subject: Re: Performance for many small requests
> > Are you using 64-bit java or 32-bit?
> 64-bit.
Might want to try -XX:+UseCompressedOops, since you have a small heap on a
64-bit JVM.
- Chuck
THIS COMMUNICAT
, the app does some quick integrity checks and write
it to disk, then returns an "ok" response to the client.
Regards,
-Tony
--- On Thu, 9/1/11, David kerber wrote:
From: David kerber
Subject: Re: Performance for many small requests
To: "Tomcat Users List"
Date: Thursday, Sep
On 01/09/2011 15:40, David kerber wrote:
> On 8/31/2011 12:25 PM, Tony Anecito wrote:
>> Hi David,
>>
>> You need to not only look at the container but it's configuration and
>> the jre that is being used. There have been a lot of improvements in
>> all areas for performance. Also, understand the s
ct: Re: Performance for many small requests
> To: "Tomcat Users List"
> Date: Thursday, September 1, 2011, 8:40 AM
> On 8/31/2011 12:25 PM, Tony Anecito
> wrote:
> > Hi David,
> >
> > You need to not only look at the container but it's
> configuration a
On 8/31/2011 12:25 PM, Tony Anecito wrote:
Hi David,
You need to not only look at the container but it's configuration and the jre
that is being used. There have been a lot of improvements in all areas for
performance. Also, understand the servlet model seems developers have
completely forgot
2010 JavaOne Outstanding Developer Award
--- On Wed, 8/31/11, David kerber wrote:
> From: David kerber
> Subject: Re: Performance for many small requests
> To: "Tomcat Users List"
> Date: Wednesday, August 31, 2011, 8:22 AM
> On 8/31/2011 10:18 AM, Francis
> GALIEGU
On 8/31/2011 10:16 AM, Mark Thomas wrote:
On 31/08/2011 15:11, David kerber wrote:
Has there been any comparison testing done in how the latest 7.x version
of TC will compare to the latest 6.0.x version, in the case of tons
(hundreds per second) of very small, quick-to-process requests?
Not th
On 8/31/2011 10:18 AM, Francis GALIEGUE wrote:
On Wed, Aug 31, 2011 at 16:11, David kerber wrote:
Has there been any comparison testing done in how the latest 7.x version of
TC will compare to the latest 6.0.x version, in the case of tons (hundreds
per second) of very small, quick-to-process re
On Wed, Aug 31, 2011 at 16:11, David kerber wrote:
> Has there been any comparison testing done in how the latest 7.x version of
> TC will compare to the latest 6.0.x version, in the case of tons (hundreds
> per second) of very small, quick-to-process requests?
>
> I have a machine that's starting
On 31/08/2011 15:11, David kerber wrote:
> Has there been any comparison testing done in how the latest 7.x version
> of TC will compare to the latest 6.0.x version, in the case of tons
> (hundreds per second) of very small, quick-to-process requests?
Not that I am aware of.
> I have a machine th
Has there been any comparison testing done in how the latest 7.x version
of TC will compare to the latest 6.0.x version, in the case of tons
(hundreds per second) of very small, quick-to-process requests?
I have a machine that's starting to croak and am moving to a new
machine, and need to dec
30 matches
Mail list logo
