http://www.youtube.com/watch?v=wDnwUHaQ9rQ
On Apr 21, 2013, at 3:20 PM, [email protected] 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 protected]> 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 protected]> >> 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/jpachod%40improve.fr >> >> 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/probert%40macti.ca >> >> 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/ramseygurley%40gmail.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]
