Marcus Crafter wrote:
>
> Hi All,
>
> We've also been experiencing such problems for the last 2 weeks or so,
> mainly a decrease in performance/response over time under reasonable
> load.
>
> We had a range of errors:
>
> o components not found: fixed recently in avalon's DefaultPool
> (also seems to have improved what was before a memory leak)
I'm glad to see this is no longer a problem. Let me know if it rears
its ugly
head again.
> o decreased performance over time (100 users lasts about 20 minutes,
> 50 users lasts about 40 minutes with our application, before
> performance drops)
What is the load (beyond number of users: time between responses, type
of resource).
> We've been using an up-to-date version of Cocoon2 from trunk CVS and
> have been following the discussions on the mailing list very closely.
Probably should use the cocoon_2_0 branch (check the site for the proper
name).
That is what is being prepared for production readiness. The main trunk
(Cocoon 2.1)
has some new/experimental components that may contribute to stability
issues and
memory leaks.
> In our situation, we've noticed that under load the application's
> performance and response time decreases dramatically, however the
> machine does recover after load has dropped. Once load drops, the
> application starts to settle down and returns to a normal state
> operating state.
The fact that Cocoon recovers gracefully is a testament to its design.
This is
part of the scalability picture. It is understandable that the response
time
will decrease under load, but check below for more information:
> During times of poor performance/response time however, our
> application server is *not* out of resources. We've been able to
> ascertain that both memory and CPU resources are available.
>
> What could cause such a phenomenon ?
Ok. There are two things that can help you: increasing the amount of
memmory
your JVM will use (the java -X options), and manipulating the pool sizes
for
the Components. Cocoon.xconf provides attributes to allow you to
manipulate
the size of Component pools for Poolable Components:
pool-min // Minimum number of Components in the pool
pool-max // Maximum number of Components maintained in the pool
pool-grow // Number of Components to add to the pool each time we run
out.
The Pool will basically turn into a Factory when the number of
Components in
the pool exceed pool-max. This is a performance drain.
We should probably ensure their use in Sitemap Components (any takers on
this?)
> Memory leaks ? I'm not sure if a memory leak would cause a drop in
> performance, unless excessive garbage collection was being done (but
> we have 2gig of RAM, of which 800 meg is not even touched)
Increase your pool sizes and cache sizes. If your JVM is not set to use
all 2 gig
of RAM, then it will perform garbage collection more often.
> Runaway threads ? Could cause such a problem, but they wouldn't allow
> the system to regain itself - or should I not assume this ?
I don't think this is a problem. You would see your CPU maxed out.
> Synchronization problems ? Could there be some synchronization issues
> there which force the jvm to queue threads up for entry to a
> particular method/code block which is considered to be a critical
> area ?
The ComponentManagement framework uses Mutexes to control access--which
is critical
for Cocoon's stability. However, if you can sustain 100 users for 20
minutes before
the slow down occurs, I doubt that synchronization is the culprit.
> Threading issues ? We've also seen cases in the log files under load
> where a single (same) request is handled by 4 separate threads, all
> starting in the same second - quite vexing.
That _might_ be your Servlet Engine. The last time I ran my tests I
used Caucho's
Resin. It is pretty decent, although it has some synchronization issues
of its own
regarding archived files (i.e. jar files). They are so severe that the
entire JVM
crashes.
Try another vendor's Servlet Engine--it _could_ be that Tomcat is the
problem if
4 threads are handling the SAME request.
> Our environment is a on a Sun Enterprise 250 (2x450mhz UltraII, 2gig
> ram), with Tomcat 3.2.3, CVS Cocoon2, and our reporting application
> (generates various html tables and pdf reports).
That sounds very impressive. Can I have one? ;P
> If you have any comments, or questions regarding what we've seen,
> please feel free to respond.
Try the tips I laid out. Recapping:
1) Make sure your JVM is set to use all 2gig of RAM (or however close
you want to be)
2) Play with the pool parameters until you have something that works
3) Try another Servlet Engine (If your problems persist then the issue
is very likely
with Cocoon)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
