> 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...) > > 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
