Leo Sutic wrote:
>>From: Vincent Massol [mailto:[EMAIL PROTECTED]]
>>
>>
>>>From: Leo Sutic [mailto:[EMAIL PROTECTED]]
>>>
>>Yes, I thought about that. But then it creates new complex questions
>>such as :
>>- when do objects that are not released return to the pool and how do
>>you implement it
>>
>
> Never. They are gc'ed.
>
>
>>- it adds parameters to the application configuration
>>
>
> Yes, but you can go with reasonable defaults.
>
>
>>So yes, if we cannot do anything else, we will use poolable components
>>but I'd rather not if I can find an alternative that is good enough.
>>
>>Isn't there synchronization also involved in pooling components ? ;-)
>>
>
> Yes, but you will not have to create the components over and over again.
> The gain here is, I think, greater than the loss you have by
> synchronizing.
>
> Basically, I'm trading synchronization times for object creation times.
Keep in mind that the cost of uncontended synchronization is minimal.
It is almost neglegent.
Also keep in mind that in some cases, the ECM *does* instantiate a new
ComponentHandler if the component is asked for during runtime. This
happens if there is an entry in roles configuration file, but nothing
in the main configuration file.
For example, suppose that the default XML parser is good enough. Rather
than take up space in the config file, the ECM will delay its creation
until it is asked for. If there is an entry for the role in the
RoleManager, the ECM will find the class name to instantiate, and create
the new ComponentHandler.
Note: the ContainerManager does not allow this by default.
>
>
>>But yes, you are right, preallocating all needed resources is the only
>>way to guarantee response times ...
>>
>
> Tried ThreadLocal variables?
On JDK 1.4 they are *really* optimized. JDK 1.3 has major improvement
over JDK 1.2. I would not recommend them on JDK 1.2.
>
> Gettin' uglier by the second, but 99.97% is a nightmare. All you need is a
> single GC run by the VM, and you're out of margin...
Hmm. Considering you have 86,400,000 milliseconds in a day, 99.97%
means that you can only 25,920 milliseconds of down time. That's almost
26 seconds (not quite, but close). To guarantee that kind of response
time, you will have to run two JVMs in parrallel at least just to avoid
overhead due to garbage collection. Depending on the amount of garbage,
a full GC cycle can cost you as much as 5 seconds. Not to mention that
partial GCs happen quite frequently (depending on if you are running
with -client or not) and cost about 1-10 milliseconds.
I will warn you: do *not* use the -Xincgc option on your JVM. While the
Full GC cycle is not used, you still end up spending more time in the
garbage collecter.
*Do* use -server if you are running JDK 1.4 or JDK 1.3 hotspot. You
will have to allocate more memmory to the JVM, but you will spend far
less time in the garbage collector. Running with the -server option
makes the ECM 8 times more efficient without doing anything else.
(my run had it 14x slower than ContainerManager instead of 114x).
BTW, -server doesn't change how frequently you visit the GC, but it
cuts the time you spend in there by a factor of almost 10. For
partial GC's, you are looking at .7 to 1 milliseconds per GC and
25-60 milliseconds per GC.
You also get the added benefit of better optimizations over time.
Partial GC happens roughly every 100-200 milliseconds in the -client
and -server options. There is an undocumented -X option to disable
manual GC's. It appears that Full GC cycles only occur when System.gc()
is called.
--
"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]>
