Re: WebObjects scalability question - WOSession?
Re: WebObjects scalability question - WOSession?
- Subject: Re: WebObjects scalability question - WOSession?
- From: Mike Schrag <email@hidden>
- Date: Mon, 15 Nov 2010 20:20:38 -0500
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 (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>> This email sent to email@hidden
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list (email@hidden)
>>>> Help/Unsubscribe/Update your Subscription:
>>>>
>>>> This email sent to email@hidden
>>>
>>> ;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 (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> --
> 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 (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden