Chuck, Darryl
I'd like to thank you both on the amazing insights of concurrency.
Learned a lot today :-)
thanx
leon
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
> From: Darryl L. Miles [mailto:[EMAIL PROTECTED]
> Subject: Re: [OT] Performance tricks with multiple tomcat instances
>
> I had read some comments that might lead others to think
> that "count++" on a java "int" type is in some way atomic.
Yes, there ar
Caldarale, Charles R wrote:
From: Darryl L. Miles [mailto:[EMAIL PROTECTED]
Subject: Re: Performance tricks with multiple tomcat instances
I would hope that JIT compiler engineers would as a minimum
implicitly add the "lock" instruction before all operations
on primitive type
> From: Darryl L. Miles [mailto:[EMAIL PROTECTED]
> Subject: Re: Performance tricks with multiple tomcat instances
>
> I would hope that JIT compiler engineers would as a minimum
> implicitly add the "lock" instruction before all operations
> on primitive types d
Leon Rosenberg wrote:
Well, personally I had collywobbles before we've gone on 2 cpu
machines, but it went well. I mean, as long as you are one cpu machine
you can be sure that your threads are never really concurrent and
atomic operations remain atomic (like ++) but in case of 2 cpus you
start
Caldarale, Charles R wrote:
From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
Subject: Re: Performance tricks with multiple tomcat instances
Tomcat APR will use one thread per connection. but APR also has non
blocking option.
Does Tomcat use the non-blocking option? (I haven&#
> From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
> Subject: Re: Performance tricks with multiple tomcat instances
>
> Tomcat APR will use one thread per connection. but APR also has non
> blocking option.
Does Tomcat use the non-blocking option? (I haven't looke
Caldarale, Charles R wrote:
From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
Subject: Re: Performance tricks with multiple tomcat instances
the select (non blocking) capability would be required
if you wanna do keep alive connections with less threads
than connections
that is why BEA
> From: Filip Hanik - Dev Lists [mailto:[EMAIL PROTECTED]
> Subject: Re: Performance tricks with multiple tomcat instances
>
> the select (non blocking) capability would be required
> if you wanna do keep alive connections with less threads
> than connections
> that is why
Caldarale, Charles R wrote:
The select capability isn't required to implement the behavior I
described. Once the request is read in over the wire, the request
object is passed off to a worker thread, and the reader thread goes back
for another one. I'm going to have to dig deeper into the Catal
> From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
> Subject: Re: Performance tricks with multiple tomcat instances
>
> Hmm, I always thought operations which are declared atomic
> are guaranted to be executed at once, for example addition.
Addition is normally not atomic; assignm
> From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
> Subject: Re: Performance tricks with multiple tomcat instances
>
> In particular, assignment to variables of any type except
> long or double is atomic.
Note this is _assignment_ not arithmetic. Depending on the capabilities
of
On 3/9/06, Caldarale, Charles R <[EMAIL PROTECTED]> wrote:
> > From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
> > Subject: Re: Performance tricks with multiple tomcat instances
> >
> > I mean, as long as you are one cpu machine you can be
> > sure that your thr
On 3/9/06, Caldarale, Charles R <[EMAIL PROTECTED]> wrote:
> > From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
> > Subject: Re: Performance tricks with multiple tomcat instances
> >
> > I mean, as long as you are one cpu machine you can be
> > sure that your thr
> -Original Message-
> From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 09, 2006 3:06 PM
> To: Tomcat Users List
> Subject: Re: Performance tricks with multiple
> tomcat instances
>
> On 3/9/06, Justin Greene <[EMAIL PROTECTED]>
> From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
> Subject: Re: Performance tricks with multiple tomcat instances
>
> I mean, as long as you are one cpu machine you can be
> sure that your threads are never really concurrent and
> atomic operations remain atomic (like ++)
On 3/9/06, Justin Greene <[EMAIL PROTECTED]> wrote:
>
> > -Original Message-
> > From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, March 09, 2006 10:28 AM
> > To: Tomcat Users List
> > Subject: Re: Performance tricks with multiple
> -Original Message-
> From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 09, 2006 10:28 AM
> To: Tomcat Users List
> Subject: Re: Performance tricks with multiple
> tomcat instances
>
> On 3/9/06, Filip Hanik - Dev Lists <[EMAIL PROTECTE
On 3/9/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
> he he, thats where bladeservers come in, of course, they are not cheap,
> and you'd probably need a SAN! ;)
yeah... and this is the point where the tco skyrockets ;:-)
>
> Filip
Leon
--
Leon Rosenberg wrote:
On 3/9/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
If I were to add my two cents, I would say the OS scheduler, the bus,
memory access all will play their part.
ie, I think you will get more juice out of 8 single CPU machines each
running a tomcat, than one ma
On 3/9/06, Caldarale, Charles R <[EMAIL PROTECTED]> wrote:
> > From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
> > Subject: Re: Performance tricks with multiple tomcat instances
> >
> > so with 4 tomcats I should reduce the number of gc threads to 2 per vm
> > an
On 3/9/06, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:
> If I were to add my two cents, I would say the OS scheduler, the bus,
> memory access all will play their part.
> ie, I think you will get more juice out of 8 single CPU machines each
> running a tomcat, than one machine with 8 CPU's,
> From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
> Subject: Re: Performance tricks with multiple tomcat instances
>
> so with 4 tomcats I should reduce the number of gc threads to 2 per vm
> and with 2 tomcats to 4 for vm to have the same number of threads as
> with single tom
xchanging other servers)...
leon
On 3/9/06, Caldarale, Charles R <[EMAIL PROTECTED]> wrote:
From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
Subject: Performance tricks with multiple tomcat instances
One of my assumption for relative bad performance is the gc. If I
install 2 or 4 tomcat
Caldarale, Charles R <[EMAIL PROTECTED]> wrote:
> > From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
> > Subject: Performance tricks with multiple tomcat instances
> >
> > One of my assumption for relative bad performance is the gc. If I
> > install 2 or 4 tomcat i
> From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
> Subject: Performance tricks with multiple tomcat instances
>
> One of my assumption for relative bad performance is the gc. If I
> install 2 or 4 tomcat instances on the same machine, I assume that if
> I'm lucky the gc i
Hi,
we are testing a new server, to check whether we can achieve higher
performance/hardware cost ratio.
The new toy is a 4-cpu double core opteron:
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 33
model name : Dual Core AMD Opteron(tm) Processor 87
27 matches
Mail list logo
