Le 2010-11-16 à 14:42, Antonio Petri a écrit : > > Of course, the sad reality is that our industry loves to just syntactically > masturbate with different languages and pretend that we're much better for it > when the reality is that basically nothing has changed in 30 years in terms > of how we actually solve problems. > > I get this as iTunes, Google and Twitter could have well been built using > Pascal (the language...)
No, because Pascal is too fat :-) At least that was one of my teachers said in college when we had to do a DOS (!!) app to send files over a NULL modem and he said that we will do the project in C because Pascal is too fat... > > On Nov 15, 2010, at 8:50 PM, Ian Joyner wrote: > > > I agree with this too. Problem or fixed complexity must be dealt with > > somewhere in the system, and arguments often abound as to where that should > > be done (almost always without people recognizing that fact). I wrote on > > that recently too: > > > > http://www.ianjoyner.name/Ian_Joyner/Complexity.html > > > > so am in vehement agreement. > > > > It's always a problem getting something to run quickly, like Twitter, to > > see if it succeeds or fails, before committing significant resources, and > > then like Twitter maybe rewriting your message queues in Scala for speed. > > (Something done by WO, I think?) > > > > But getting something quickly done in WO, might be a problem. Pascal's > > words about "learning cliff" still ring in my ears ;-) > > > > Ian > > > > On 16 Nov 2010, at 12:20, Mike Schrag wrote: > > > >> I think you also have to weigh the dramatically more complex security and > >> protocol required to handle state on the client. You get a huge amount for > >> free with WO in terms of state transition management that you have to > >> build yourself if you use almost any other system. You also get a large > >> amount for free with WO with respect to security because you can count on > >> "that you called this action means you were allowed to see this action," > >> whereas a traditional restful system requires security enforcement for > >> every action. Also consider that your site isn't iTunes, Google, or > >> Twitter. Most applications don't have to scale all that much, and almost > >> certainly are within the realm of a few servers and dumping ram into your > >> box. > >> > >> I also don't care what tools and frameworks you built your system with. If > >> you DO become iTunes, Google, or Twitter, your app won't scale. Period. > >> I've never seen a system that scales without investing substantial > >> engineering effort in profiling and rearchitecture after deployment. If > >> you built your app with rest, all you're doing is shifting your load in > >> other ways. Like Chuck said, you get a lot of caching for free with WO > >> that you have to figure out how to get back with stateless architectures. > >> And the most common method? Shared object caches -- Memcached, Coherence, > >> etc. WO/EOF essentially has this architecture (on the persistence side), > >> but with local caches in the snapshot cache that serve whatever sessions > >> you send to it. With a little bit of work with sharding your users, you > >> can take advantage of that by routing users to appropriate instances. > >> > >> The moral of the story is that every technology sucks, so you might as > >> well just build it fast so it can suck in production faster and you can > >> move on with your life. > >> > >> ms > >> > >> On Nov 15, 2010, at 8:02 PM, Chuck Hill wrote: > >> > >>> > >>> On Nov 15, 2010, at 4:53 PM, Ian Joyner wrote: > >>> > >>>> On 16 Nov 2010, at 11:35, David LeBer wrote: > >>>> > >>>>> > >>>>> On 2010-11-15, at 7:09 PM, Ian Joyner wrote: > >>>>> > >>>>>> (Not that I'm doing any WO these days, but I still like to follow.) > >>>>>> > >>>>>> One thing that has always worried me about scalability is keeping the > >>>>>> per user "application state" on the server in WOSession. Knowing more > >>>>>> about REST now, this is very unrestful and not stateless, which means > >>>>>> will not scale. > >>>>> > >>>>> I don't see why something being unrestful and not stateless > >>>>> automatically equates to not being able to scale. Perhaps you could > >>>>> explain. > >>>> > >>>> The problem is that once you get 1000s and millions of users you have > >>>> the problem of memory size storing all that session information in > >>>> memory on the server. > >>> > >>> As with any system, the number of concurrent users that can be handled on > >>> a given server depends on both the application and the technology that it > >>> is built on. I will grant you that WO probably uses more memory per user > >>> than many technologies. But memory usage is only one part of the > >>> equation. > >>> > >>> > >>>> Server must also manage all these sessions - clean them out every so > >>>> often. And (in middleware systems I worked on in the 80s) keep track of > >>>> state transitions with FSMs, etc. > >>>> > >>>> Yes you need session state, ie context, but it should be kept on the > >>>> client, which sends it along with each request. Thus user state is kept > >>>> only on the client which makes recoverability easier too, because if the > >>>> server is rebooted, client can continue oblivious to any problem. > >>> > >>> Yes, recoverability is a nice to have feature, but really how often is it > >>> actually needed? Restarts should be planned with the instances being set > >>> to Refuse New Sessions so that there are no active sessions on a machine > >>> when it is rebooted. So recoverability is only strictly needed for > >>> accidental restarts, kernel panics and such. > >>> > >>> The problem with keeping the WO state on the client is that WO keeps a > >>> LOT of state (EO, changed attributes, page cache, etc). You would need > >>> to have a finely tuned way of getting that back and forth from the > >>> client, otherwise performance would suffer mightily. > >>> > >>> Chuck > >>> > >>> > >>> > >>> > >>>>> > >>>>>> How is this problem dealt with these days? WOnder? > >>>>>> > >>>>>> Thanks > >>>>>> Ian > >>>>>> > >>>>>> On 16 Nov 2010, at 03:43, Greg Lappen wrote: > >>>>>> > >>>>>>> Hi everyone, > >>>>>>> > >>>>>>> Based on using WO for the last 7 years, I have observed a couple of > >>>>>>> things that seem to be a performance bottleneck in WebObjects. I > >>>>>>> know that Apple uses WebObjects on a large scale for iTunes and > >>>>>>> ecommerce, so there must be solutions to these. > >>>>>>> > >>>>>>> #1 - Only one thread can be processing at once. I seem to recall > >>>>>>> that this is a limit in EnterpriseObjects but it's been a while. > >>>>>>> > >>>>>>> #2 - EnterpriseObjects caches every object from the database. > >>>>>>> > >>>>>>> With that being said, how can you horizontally scale your application > >>>>>>> layer? If you setup more instances of your app, they each have their > >>>>>>> own caches, which will be out of sync with each other. Is there a > >>>>>>> commonly used framework for doing distributed cache management? And > >>>>>>> is it possible to make your applications multithreaded so page > >>>>>>> requests can be processed concurrently? > >>>>>>> > >>>>>>> Thanks! > >>>>>>> > >>>>>>> Greg > >>>>>>> _______________________________________________ > >>>>>>> Do not post admin requests to the list. They will be ignored. > >>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > >>>>>>> Help/Unsubscribe/Update your Subscription: > >>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/ianjoyner%40me.com > >>>>>>> > >>>>>>> This email sent to ianjoy...@me.com > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Do not post admin requests to the list. They will be ignored. > >>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > >>>>>> Help/Unsubscribe/Update your Subscription: > >>>>>> http://lists.apple.com/mailman/options/webobjects-dev/dleber_wodev%40codeferous.com > >>>>>> > >>>>>> This email sent to dleber_wo...@codeferous.com > >>>>> > >>>>> ;david > >>>>> > >>>>> -- > >>>>> David LeBer > >>>>> Codeferous Software > >>>>> 'co-def-er-ous' adj. Literally 'code-bearing' > >>>>> site: http://codeferous.com > >>>>> blog: http://davidleber.net > >>>>> profile: http://www.linkedin.com/in/davidleber > >>>>> twitter: http://twitter.com/rebeld > >>>>> -- > >>>>> Toronto Area Cocoa / WebObjects developers group: > >>>>> http://tacow.org > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Do not post admin requests to the list. They will be ignored. > >>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > >>>> Help/Unsubscribe/Update your Subscription: > >>>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net > >>>> > >>>> This email sent to ch...@global-village.net > >>> > >>> -- > >>> Chuck Hill Senior Consultant / VP Development > >>> > >>> 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/products/practical_webobjects > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Do not post admin requests to the list. They will be ignored. > >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > >>> Help/Unsubscribe/Update your Subscription: > >>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com > >>> > >>> This email sent to msch...@pobox.com > >> > > > > _______________________________________________ > > Do not post admin requests to the list. They will be ignored. > > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > > Help/Unsubscribe/Update your Subscription: > > http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com > > > > This email sent to msch...@pobox.com > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/antonio.petri%40googlemail.com > > This email sent to antonio.pe...@googlemail.com > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca > > This email sent to prob...@macti.ca
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
