Intriguing :) The presentation is there for anyone interested http://fr.slideshare.net/wocommunity/persistent-sessionstorage This one might be of interest as well http://fr.slideshare.net/wocommunity/web-objects-optimization
And thanks ramsey for the video :) I may come back sooner or later on the topic. ++ 2013/4/22 <[email protected]> > 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/archive%40mail-archive.com This email sent to [email protected]
