• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: WO blocking/threading question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.


  • Follow-Ups:
    • Re: WO blocking/threading question
      • From: Hsu <email@hidden>
    • Re: WO blocking/threading question
      • From: Michael Engelhart <email@hidden>
References: 
 >WO blocking/threading question (From: Michael Engelhart <email@hidden>)
 >Re: WO blocking/threading question (From: David Teran <email@hidden>)
 >Re: WO blocking/threading question (From: Michael Engelhart <email@hidden>)

  • Prev by Date: Re: PostgreSQL Adaptor and Plugin
  • Next by Date: Re: WO blocking/threading question
  • Previous by thread: Re: WO blocking/threading question
  • Next by thread: Re: WO blocking/threading question
  • Index(es):
    • Date
    • Thread