Re: WO blocking/threading question
Re: WO blocking/threading question
- Subject: Re: WO blocking/threading question
- From: Michael Parlee <email@hidden>
- Date: Sun, 15 Aug 2004 12:41:56 -0700
Michael, David and others,
I'm also very interested in performance issues in deployed WO apps.
All of my WO development to date has been for intranet apps with a
maximum 10-20 simultaneous connections, so performance has never been
much an issue. In fact performance has been noticeably better in my WO
apps than the Perl and PHP they replaced.
I've also done some J2EE development recently and in everything I've
read on J2EE, performance and memory footprint is always a primary
concern. What are other people's thoughts on this matter? As David
pointed out, the Apple WO sites seem to approach the problem with a
large number of instances. What about deploying in a servlet
container? The adaptor servlet must be multithreaded as per the
servlet specification, but does it forward incoming requests to a
single instance of the WO application? Is that configurable somewhere?
BTW, I'm not bashing WO here, I just want to understand the performance
aspect a little better.
Thanks,
Mike
On Aug 15, 2004, at 8:55 AM, Michael Engelhart wrote:
Hi David -
On Aug 14, 2004, at 5:29 AM, David Teran wrote:
Hi Michael,
WO uses one EOF stack by default. All EOEditingContexts' object store
is one and the same. You can create additional EOF stacks like this:
// stack # 1
EOObjectStoreCoordinator osc1 = new EOObjectStoreCoordinator();
EOEditingContext ecStack1 = new EOEditingContext(osc1);
// stack # 2
EOObjectStoreCoordinator osc2 = new EOObjectStoreCoordinator();
EOEditingContext ecStack2 = new EOEditingContext(osc2);
Now if you do a fetch with ecStack1 which takes lets say one hour or
so you can do another fetch in parallel with ecStack2. Each EOF stack
uses at least one JDBC connection.
Thanks for that information. That's really helpful information to
have in my back pocket!
the RR loop is single threaded by default, you can turn it on by
putting 'WOAllowsConcurrentRequestHandling=true' in a properties file
or as commandline argument. Then the RR loop runs in multithreaded
mode which means multiple request are processed in parallel. If each
request uses another EOF stack then you have parallel database
access, too.
Be aware that multithreaded apps tend to have more EOF deadlocks, so
you really should know what you are doing. Some people are reporting
that they have to problems with concurrent request handling as long
as they are using the sessions default editingcontext, but fetching
everything in one editingcontext is not a good idea (imho).
So if the RR loop is single threaded by default that means that if I
have 100 concurrent users all on 24600 bps modem connections that all
need to download a 50 k JPEG (i chose that number as it implies
roughly a 2 second download at 24.6kbps), that WebObjects will block
on each of those users while the output is being sent to the client or
just that the inital page generation is blocked. if it's blocking
all the way back to the client I'm at a loss as to how webobjects can
manage high traffic sites if it does at all. Also if the EOF
deadlocks occur, can these happen on pages that are read-only? I'm
not sure what happens in an EOF deadlock. Does the application stop
responding?
On my site the majority of the long processes are making a webservices
connection and have no EOF code in them so I'm wondering since I'm
doing these webservices requests in a WOLongResponsePage, being that
it launches a a separate thread, will this will allow for concurrent
page access without setting the application to be multi-threaded as a
whole and possibly mucking up the EOF parts of my application. Does
anyone know how WOLongResponse is treated in that regard?
I'm in the process of rebuilding a highly trafficked commercial site
originally written with Servlets/JSP/JDBC in WebObjects right now and
am very concerned that it's single-threaded RR is going to be a major
bottleneck even for pages that aren't doing any JDBC access at all.
It seems most posts always tend to point to the Apple Store as being
the reason that WO is scaleable but even if the store is doing a $1M a
day in transactions that's really only at most maybe 2000 orders a day
which isn't high-volume by any stretch of the imagination.
Thanks again for any feedback.
Mike
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.