• 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: Scaling WebObjects at the web-server/proxy level
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scaling WebObjects at the web-server/proxy level

  • Subject: Re: Scaling WebObjects at the web-server/proxy level
  • From: Ramsey Gurley <email@hidden>
  • Date: Sun, 21 Apr 2013 15:27:18 -0700
http://www.youtube.com/watch?v=wDnwUHaQ9rQ

On Apr 21, 2013, at 3:20 PM, email@hidden wrote:

Ramsey did a session about this last year at WOWODC. Check the slides on slideshare.net or become a member to get access to the recording.

Envoyé de mon iPhone

Le 2013-04-21 à 18:19, "Joseph Pachod" <email@hidden> a écrit :

Hi Dov

Reading you it feels like EOF/Wonder could store sessions between requests, sparing an hell of a lot of ram and increasing scalability at the same rate. Is this really so ? If yes, is this described anywhere ? I would love to dig more in this direction. 

Currently, with an application full of state,  we put around 20 sessions per instance (with an xmx of 480 but average use of 200Mo or so). Being able to serialize down the sessions between requests would blow this like hell I guess... so I would love to be able to do so :)

Thanks in advance, and I hope I'm not day (or rather night by now) dreaming !

++
joseph



2013/2/27 Dov Rosenberg <email@hidden>
My company has built a very scalable knowledge management solution that is currently running on Apple.com's support site. We see very large traffic numbers on a regular basis (>20M page view daily).

There are a number of approaches you can take to improve your overall scalability:
  • We utilize a lot of small instances with a load balancer in front. We deploy as a Servlet instead of using the WOtaskd stuff. I have seen performance issues when trying to use the mod_jk approach. A simple load balancer that respects sticky sessions works just fine. Hardware load balancers tend to be more sophisticated in terms of their load balancing schemes
  • Use a content caching service like Akamai to fetch once from your web app and then cache the results for a longer period of time. Most of our app is write once read many times. 
  • Try to avoid caching data that is tied to a session - i.e. user preferences, you will run out of memory. Instead cache the data that is shared across sessions - i.e. like a document
  • Minimize the use of the undo stack in your EOF configuration - most of the time you don't need an undo stack in a web based application. Avoid using session based EOEditingContexts - create one when you need it and make sure to clean up after you are done with it
  • Use as many stateless WOComponents as possible. Minimize your memory footprint as much as possible
  • Ensure that your sessions can be fully serialized - this will allow you to take advantage of your servlet engine's clustering capabilities
  • If you absolutely must have a stageful service and you need to have fail over capability, consider using a DB based session store. It is slower than the default memory one, but allows you to have greater flexibility in load balancing and deployment architectures
  • Be careful of your EOF relationships. EOF is great for transactional interactions, but it can cause big performance issues if someone inadvertantly does something stupid like fetching all records on a large table while trying to access a key path. You need to make sure to run your app in SQL debug mode under various use cases to make sure your fetches are correct and efficient. Otherwise your house of cards will collapse under load
  • Break your app into smaller services instead of having monolithic applications. This provides better flexibility in scaling the pieces that are under heavier load 

WO apps can handle very heavy traffic volumes if they are architected correctly even without multiple EOF stacks.



Dov Rosenberg
407-310-8316
email@hidden


On Feb 27, 2013, at 12:18 AM, Chuck Hill <email@hidden> wrote:

Not much response to this.  :-)



On 2013-02-26, at 6:10 AM, Brook, James wrote:

I have a question about a general approach to high scalability for
WebObjects applications. In particular I am interested in how people
handle the incoming requests before they reach the application instances.
I am confident that the Java applications scale. The sort of load I am
talking about is in the order of 10s of thousand of requests per second.
Presently we use Apache 2.2 with the 'worker' MPM and we experience
serious bottlenecks in mod_WebObjects under load (perhaps because of
Solaris).

I have seen an issue on Solaris, but never resolved it to Solaris or something else.


So, I guess the questions are:

* Do people use mod_WebObjects for handling 10s or even 100s of thousands
of requests per second?

Certainly not on a single Apache machine, I'd guess.


* Do people use Apache? If so, is everyone using prefork (not very
scalable) or do people use other MPMs like 'worker' or even the 'event'
MPM in Apache 2.4? I don't have much confidence that the present WO
adaptor code is thread safe.

So far, I have Apache.  But not on Solaris for a long time.  And I have no comment on the WO adaptor code.  It has been years since I waded into that.



* Are people exposing their WebObjects apps behind alternative web servers
with an 'event loop', e.g. nginx or perhaps directly behind a hardware
load balancer?

A load balancer in front of multiple Apache machines, yes.  You would need to do something to ensure that requests are routed correctly, unless your apps are session-less or have mobile sessions.


* Have people built custom solutions for discovery, load-balancing and
failover that still take advantage of wotaskd, the app heartbeats, etc?
Perhaps Java based with Netty or some sort of alternative modern adaptor?

I have not.


* Are people just freezing their config and using Apache with
mod_proxy_balancer?

I think that Anjo did that.


* Does anyone here serve similar volumes of traffic?


* Finally, is there a need for a more modern proxy for WebObjects? What
direction would be best to take? Are there people who would want to be
involved in building something if there is a perceived need for it? I
think we would happily make a financial contribution for a modern and
elastic deployment stack if someone in the community is interested in
working on it.

I would be really interested to hear if anyone is facing similar
challenges.

My guess is that there is a need, but probably not a huge one.  Not many of us need to scale to those levels.  


Chuck


--
Chuck Hill             
Executive Managing Partner, VP Development and Technical Services

Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.    
http://www.global-village.net/gvc/practical_webobjects

Global Village Consulting ranks 13th in 2012 in BIV's Top 100 Fastest Growing Companies in B.C!
Global Village Consulting ranks 76th in 24th annual PROFIT 200 ranking of Canada’s Fastest-Growing Companies by PROFIT Magazine!












_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)

This email sent to email@hidden


 _______________________________________________
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


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
References: 
 >Re: Scaling WebObjects at the web-server/proxy level (From: Joseph Pachod <email@hidden>)
 >Re: Scaling WebObjects at the web-server/proxy level (From: email@hidden)

  • Prev by Date: Re: Wonder 6.0.2 release
  • Next by Date: Re: Scaling WebObjects at the web-server/proxy level
  • Previous by thread: Re: Scaling WebObjects at the web-server/proxy level
  • Next by thread: Re: Scaling WebObjects at the web-server/proxy level
  • Index(es):
    • Date
    • Thread