Re: Performance problem before and after growing WOWorkerThreads number
Re: Performance problem before and after growing WOWorkerThreads number
- Subject: Re: Performance problem before and after growing WOWorkerThreads number
- From: Benoit Cantin <email@hidden>
- Date: Tue, 12 Jun 2007 09:25:06 +0200
Chuck Hill wrote:
Hi Benoit,
Hi Chuck,
Thank you for your reply.
On Jun 8, 2007, at 11:24 AM, Benoit Cantin wrote:
On one of our apps, we have what I describe in the subject.
The growing worker threads is not the problem It is just a symptom of
the problem.
Application runs on xserve dual G5 and wo 5.3.3. Only one instance,
multithread disabled. Adaptor settings are given in the attachement
(sorry for this).
The workflow is the following : only 3 users connect to the webobjects
backend through one direct action. In this direct action, there is a
call to the the session().defaulteditingcontext() method initiating
the creation of a session. That is what I understand from the doc.
Just calling session() is sufficient.
OK. As our DAs don't need to maintain an active session to do their job,
we decided to switch to a new EOEditingContext() and to manage lock and
unlock as described in the wikibooks
http://en.wikibooks.org/wiki/Programming:WebObjects/EOF/Using_EOF/Context_and_Database_Locking
Now we come to about 250 sessions created, then log says :
[2007-06-08 19:54:00 CEST] <WorkerThread14>
<com.webobjects.appserver._private.WODefaultAdaptor>: Growing number
of WOWorkerThreads to 32
That is a symptom of a bug in your application. Having more than 16
worker threads is either a sign of a bug, or an indication that you need
to run more instances as load is too high.
But just before and after, application becomes sloooooooow. It
processes one request a minute and then application becomes unreachable.
It is the slowness that is causing the extra worker threads to be
created. You need to find why it is getting slow. I suspect that your
sessions are not terminating properly and that memory is running out and
the app is spending too much time doing garbage collection. If could be
a deadlock, but then the app should just stop responding, not get slow.
So that's not a deadlock since app doesn't stop responding. And you are
right about memory running out. Now that we have made a couple of
amendments (especially on DAs), this trouble seems to have been solved.
Until now, we couldn't add more instances due to optimistic locking
problems. We are confident for this to be quickly solved too. Once this
will be done, we will add more instances, and we hope that slowness
problems will be definitely solved.
My question is : from where does this problem come from ? Can this be
from WODefaultAdaptor settings which I didn't modify ? sessions in
direct action ? Anything else.
Please let me know if you have ideas or wish any other info.
Check the app log for exceptions. Have you overridden awake, sleep, or
terminate in the Session class? Don't let those methods throw any
exceptions!
We have not overridden theses methods.
Thanks Chuck.
--
Benoit Cantin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden