Re: Converting WO app to Multithreaded WO app...
Re: Converting WO app to Multithreaded WO app...
- Subject: Re: Converting WO app to Multithreaded WO app...
- From: "Jerry W. Walker" <email@hidden>
- Date: Mon, 9 Apr 2007 07:49:25 -0400
On Apr 9, 2007, at 5:12 AM, Shravan Kumar.M wrote:
Hi Group,
We have a WebObjects built application. Its performing slow and it
becomes even slow when multiple users access the application, it
crashes, it times out and so on.
Can any one please add their excerpts to my below questions:
1) What is the effort required to convert my WO app (or) in general
a WO app to a Multithreaded application ?
Actually, it starts out that way as a Java application, since Java
does some basic multi-threading (Java finalization is done
asynchronously). WO adds concurrent queueing of requests without any
effort on your part at all. However, WO serializes handling of those
requests by default. Two things are required, then, for WO to handle
requests concurrently, the first trivial, the second much harder:
* first, you need to tell WOApplication that you want it to handle
concurrent request handling. You can do this with a runtime parameter
(-DWOAllowsConcurrentRequestHandling=true) or by overriding
allowsConcurrentRequestHandling in your Application to return true. I
recommend the latter, since, as David Neumann once said, it provides
a more declarative method of indicating that you've dealt with the
second issue than a runtime parameter does.
* second, you need to make sure that your application is thread
safe, a more difficult issue. By default, WO runs with a single EOF
stack and generally takes care of locking/unlocking it appropriately.
So long as you, in turn, appropriately lock and unlock any
EOEditingContexts that you create, (that is, any that you use other
than your Session's defaultEditingContext and the shared editing
context, which are both locked automatically by the session) you
should generally be OK. Google for MultiECLockManager to help you here.
However, if you want to create multiple EOF stacks, than locking can
be a bit trickier. In fact, trickier than I care to discuss at length
here. Google for it or buy Hill & Mallais's Practical WebObjects book
which discusses these issues in a very useful way.
2) What are the pros and cons of the Multithreaded WebObjects
application ?
Generally the same as for any multithreaded application with the
exception that WO does the multithreading of request queuing for you
painlessly.
PROS:
* When used under the right circumstances, can help you avoid some
sessions waiting for previously dispatched requests that take a long
time.
* Gives some programmers warm fuzzies that they can handle
multithreading (whether it's true or not).
CONS
* Can expose bugs that are much more difficult to track down than
those in a single threaded request handling environment.
* Typically doesn't provide a great deal of payback unless running
with multiple EOF stacks, since the EOF stack can become the
bottleneck that the single threaded sessions first seemed to be.
* Increases maintenance costs in general.
3) Also, can you tell me any efficient tips to debug the
application for finding out what is sucking the application
performance ?
There are several things you can do:
I would first set EOAdaptorDebugEnabled to true to print out the
generated SQL statements. My general experience has been that tuning
EOF by monitoring and optimizing its SQL generally yields greater
rewards and comes at a lower cost than multithreading the application
beyond what WO provides by default.
There are two things to look for, here. The first is that you're
getting the maximum benefit from each database access, since those
accesses tend to be the most expensive things that WO does. Be sure,
for instance, that the application is not fetching some large array
of EOs, then individually firing faults on each of the EOs in that
array to bring in related EOs. The second is to check the times for
several accesses to confirm that you're not running into a database
indexing problem. If your database has not been configured with the
appropriate indexes, it can run more slowly by multiple orders of
magnitude.
If that didn't provide the kinds of speedups you were looking for,
then start timing your request-response loops. There are finer
grained methods and tools for doing this, but they don't come to mind
immediately (it's early here) and can be found relatively easily by
Googling on WO optimization.
4) Any other directions towards solving this problem are Welcome ?
Recognize that it's nearly trivial to run multiple instances of a WO
application so that request handling can be distributed among them.
This can provide many of the benefits of multithreading while nearly
retaining the simplicity of single threading. The biggest issue that
you will encounter here is keeping the instances synchronized against
the database.
There are two popular approaches for doing this, the first,
ERChangeNotificationJMS framework, came from David Neumann, updated
for more recent versions of WO by Gary Teterd. The second is embedded
in Project Wonder. For more information on these approaches, check
the page at:
http://en.wikibooks.org/wiki/Programming:WebObjects/EOF/
Using_EOF/Multiple_Stacks_or_Instances
Hope this helps.
Regards,
Jerry
Looking forward to all your help. Let me know in case you need any
other info.
Thanks & Rgds,
Shravan Kumar.M
"Let us learn from the past to profit by the present,and from the
present to live better in the future."
--William WordsWorth
---------------------------------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40gmail.com
This email sent to email@hidden
--
__ Jerry W. Walker,
WebObjects Developer/Instructor for High Performance Industrial
Strength Internet Enabled Systems
email@hidden
203 278-4085 office
_______________________________________________
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