avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: Performance questions about ECM
Date Mon, 11 Mar 2002 10:36:59 GMT


> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: 11 March 2002 10:15
> To: Avalon Developers List
> Subject: Re: Performance questions about ECM
> 
> Vincent Massol wrote:
> > Thanks all for your performance tips ! :-)
> > I do really appreciate your help.
> >
> > I haven't mentioned it my previous emails but the application is
already
> > written (the first version which is almost the one that will be
> > released) and has already been tested in a lab using big hardware.
> >
> > We wanted to verify early that we could achieve the result ... and
it
> > worked ! We have sized the memory so that we never have full GC that
> > takes 5 seconds (our GC take max. 20 ms if I remember correctly). We
are
> > doing roughly 25 TPS (about 10-15 SQL queries for each request - we
have
> > reduced it to the minimum -, 20% write and 80% read) on a Sun 450
Mhz,
> > on 1 CPU (we are using 4 way CPUs and have bound each weblogic
instance
> > to a given CPU - 3 CPUs are bound to 3 WL instance and the last one
is
> > for the OS - We have tried all combinations possible and that was
the
> > best for our applications) => we're doing 75 TPS on a 4 way CPU box.
> > This within the 99.97% response time < 1s. And consistently (we left
the
> > test running during full nights) ... :-)
> 
> Impressive.  Now, how close to 1s are you?
> 

I don't have the figures in head but as far as I recall almost all
queries (more than 99% I think) were in the 0-500ms range and then a few
in the 500ms-1s range. It really depends on how much we push the
application. Under a well-controlled load (which is our case as we
control how many customers can log in the system before it hits the
application server) it seems to work consistenly. We're only getting
longer responses when we tried to have to many clients for a given WL
instance. The figure of 25 TPS I gave is about the maximum we can get
before it starts to degrade, so we'll either have to go to a slightly
lower number in production or tweak a bit more our application (there
are still some tweakings we can do).

> > Now, as I said, the application is not completely finished and we're
> > using more and more Avalon components (whereas in the tested version
we
> > were only using a few for technical services - we are now using
Avalon
> > component for business services). Thus my worries about the
> > synchronization stuff.
> 
> Again, if you have mostly ThreadSafe components, you are going to see
> the least impact.  That is the approach for Phoenix blocks and it
works
> well.
> 
> > I agree with all you have said. However, my biggest fear (and you
have
> > not yet convinced me !) is that even though synchronization is fast
it
> > will still block *all* threads during that time. Object creation may
> > take a bit longer but they won't block any other thread. So I'm more
> > worried about synchronization.
> 
> No, that is not an accurate statement.  It only blocks threads that
are
> *contending* for the same resource.  

Right. I spoke too fast ... There will still be a lot waiting for that
resource as all the threads are doing the same job.

> The BucketMap reduces the chance of
> thread *contention* to very little.  (I would always make sure the
> bucket size of the map is more than the threads used to process
> transactions 255 is a good number--and the default).  If you have 100
> threads all accessing the same BucketMap, it will not cause any one
> thread to block unless they are both going for the same bucket.
> 
> Because I have observed that if the number of buckets is a power of
two,
> I caused the constructor to never allow that to happen.  As it is now,
> we have a nicely dispersed system so that the number of threads
> contending for the same resource is very low.  But the statement
saying
> it will block *all* threads on access is flat out wrong.
> 
> It will only block threads that access the same bucket.
> 
> If you want to ease your mind, you can build a quick test program that
> creates 1000 objects, and perform the same hash algorithm for the
> BucketMap on those objects.  The hash algorithm is this:
> 
> object.hashcode() % m_numBuckets;
> 
> The default number of buckets is 255.  Hopefully you will see only a
few
> buckets used a little more than the others.
> 
> The bucket level is where thread contention can happen.  You should
> not see unnecessary thread contention.
> 

Ok. Thanks. I'm m ore convinced now ! :-) Anyway, we'll run some
profiling soon and we'll see who is taking the time.

> > WRT to the ComponentHandler being created at runtime, it won't
happen
> > for us as we define all our components in the ECM config file.
> >
> > Does anyone know if a dispose-less CM implementation with no
> > synchronization exist somewhere ?
> 
> 
> DefaultComponentManager in Framework--but it has no support for
anything
> but ThreadSafe components.
> 

Thanks a lot for your extensive answers. You rock !
-Vincent




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message