Vincent Massol wrote:
>
>>-----Original Message-----
>>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>>Sent: 11 March 2002 10:15
>>To: Avalon Developers List
>>Subject: Re: Performance questions about ECM
>>
>>Vincent Massol wrote:
>>
<snip/>
>>>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).
So you are doing well.
One thing you might consider is instrumenting your code. Lief is in the
process of changing class names and package names, but as it stands
right now, the AltProfile package in Excalibur is working, and quite
useful. We don't have the ability to attach to an external JVM that
is already running, but we do have the ability to get some fine grained
instrumentation working. The graphs are very useful as they also
average the values so you can see the trends superimposed over the
actuals.
<snip/>
>>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.
Yes, all threads are doing the same job, but are they making the same
requests at the same time each time?
One thing you can do if you want to cheat a little is to make your
components resettable. The current pool package has an interface
named Recyclable. When you return the class to the pool, it calls
the recycle() method on the component. That way the component
gets returned to its original state.
Now, If you grab an instance of this type of component at the
initialization stage, you can manually call recycle() at the end
of the request. That way each thread can have their own copy of
the component, and you don't have to worry about the ECM at all.
It's cheating, but it works.
<snip/>
>>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.
Sounds good. If you find anything alarming in our code, let us
know.
The rest of the time can be fine tuning your queries, and other
issues.
> Thanks a lot for your extensive answers. You rock !
> -Vincent
Hey, I'm supposed to issue those compliments ;P
Hopefully we have helped you.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
