cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject [C2] ComponentManager/Selector Rearchitecture
Date Mon, 19 Mar 2001 14:13:44 GMT
I believe I fixed the issues with Cocoon reusing Parser objects in a high transaction
environment.  The result was a serious rearchitecture of the ComponentManager and
Selector objects so that they use ComponentFactories to create and prepare objects.
Also, with some inventive approaches, I made sure that the Component is always returned
to the correct pool.  That way we can have multiple instances of say, the SVG serializers
with different configurations, and the Components will be returned to the propper pools.

This also greatly reduced the complexity of the Component Management Infrastructure,
and reduced the amount of duplicate code.  As a result of the reduction in complexity,
there is a real increase in speed when accessing Components.  This translates to an
additional 1-5 milliseconds per call.

Also, thanks to the hard work of Dims, Scott, and Santiago, Cocoon2 has a truly stable
pipeline with real thread safety.  For simple transformations like the "forms/add-department"
URL in the Cocoon samples you are looking at response times as low as 90 to 250 ms under
heavy load.  For more complex transformations with 5 TraxTransformer stages, you are looking
at 350 to 575 ms under heavy load.  NOTE: All times specified are on an Athlon 750 w/256MB
RAM running W2K and Sun JDK 1.3.0_01 and JVM memmory set to 256MB.

All in all, I think we have an incredible piece of work here--with speeds that rival
commercial offerings.  Doing the same type of componentized pages in a markup based
scripting language (like ColdFusion), results in 900 to 1250 ms--and is much more
difficult to maintain the code.

With Content Aggregation and Caching (which on my machine may not be necessary...)
we will have truly Insanely Great (TM) software (appologies to Steve Jobs for ripping
off his slogan).  We still have Garbage Collection cycles (there are alot of Strings
created and destroyed), but there impact is lessened do to the objects being smaller
and us being wiser with pooled and thread-safe resources.

To unsubscribe, e-mail:
For additional commands, email:

View raw message