If you have any content that is not sooo dynamic and may be cached (for example public pages from a content-management system), binding all these pages to direct actions and make them cacheable is obviously a good idea. Then you are able to place a caching reverse proxy in front of your site and you can finetune the caching behaviour. I think varnish is the proxy to choose in this case, its really great.
Markus Am 27.02.2013 um 14:37 schrieb Dov Rosenberg: > 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/markus.stoll%40junidas.de > > This email sent to [email protected] -- Dr. Markus Stoll (Geschäftsführer) [email protected] junidas GmbH, Aixheimer Str. 12, 70619 Stuttgart Tel. +49 (711) 4599799-11, Fax +49 (711) 4599799-10 Geschäftsführer: Dr. Markus Stoll, Matthias Zepf Amtsgericht Stuttgart, HRB 21939
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
