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 protected] On Feb 27, 2013, at 12:18 AM, Chuck Hill <[email protected]> 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 protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/dov%40cfl.rr.com > > This email sent to [email protected]
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
