why would server one have 1000 users while server two and three are empty? do you mean that in the time between user starting a heavy task and your loadbalancer receiving a cpu-load update from server one it has already received 1000 new requests from 1000 users while server two and three have not received any?
while roundrobin allows you to *more* evenly distribute the load, sticky sessions do a pretty good job as well. further, you should not have any heavy tasks running inside servlet threads. as soon as you have any state roundrobin becomes inefficient because you either have to replicate the state to all other nodes or to a central resource like a db. with stickysessions you simply have a backup-buddy node and only replicate state between those two. so i guess what i am trying to say is: round-robin is great for serving static content, for webapps its uselss unless your application is completely stateless. just my two cents, if it were up to me we wouldnt even introduce the complexity of supporting round robin with direct render strategy. -igor On Fri, Mar 13, 2009 at 12:08 PM, Victor Igumnov <[email protected]> wrote: > @martin > > REDIRECT_TO_RENDER did not work in my case as well. Possibly I might have > screwed something up? > > @Johan > > The point of non-sticky sessions is to have even load distribution on your > cluster. What happens when you have 1,000 users dependent > on server1 that is processing some heavy background task for one of the > users? Server2 and Server3 will sit idle. > > That said, in our case, a two server sticky session setup has been working > out wonderfully. It all comes down to a decent site architecture > that will make or break your site under load. > > -Victor > > > > On Mar 13, 2009, at 3:58 AM, Martin Grotzke wrote: > >> On Wed, 2009-03-11 at 20:09 +0100, Johan Compagner wrote: >>> >>> thats impossible to do completely >>> A refresh of a browser is for example 1 >> >> Ok, from a technical/academical point of view this is valid. However, >> GET requests should not modify any data. For POST-requests the user also >> has to confirm that form data is resent. Also users pressing F5 (and >> confirming resending of data) all the time are not as common as the well >> known double-clickers... >> >> Did you really had issues with this? What was the setup/conditions in >> this case? >> >>> >>> And that would be quite annoying that you have to do that because you >>> have >>> some kind of configuration on the serverside >> >> What do you want to say with this? I don't understand this. >> >> Cheers, >> Martin >> >> >>> >>> johan >>> >>> >>> On Wed, Mar 11, 2009 at 18:17, Martin Grotzke >>> <[email protected]>wrote: >>> >>>> Hi, >>>> >>>> One would need to handle this on the client side, by disabling >>>> buttons/links when they are clicked. Also AJAX communicatoin has to be >>>> handled, as this is also often a candidate that triggers multiple >>>> requests running in parallel. >>>> >>>> Cheers, >>>> Martin >>>> >>>> >>>> On Wed, 2009-03-11 at 17:45 +0100, Johan Compagner wrote: >>>>> >>>>> In my point of view none sticky sessions are just broken or can be >>>>> broken >>>>> very easily >>>>> I dont know exactly how all the implementations work but does this >>>> >>>> example >>>>> >>>>> all ways work? >>>>> >>>>> a user clicks on a button >>>>> that button click does take some time and in the mean time a user >>>>> clicks >>>> >>>> on >>>>> >>>>> the same or another button >>>>> >>>>> In a sticky session configuration this works fine. Wicket makes sure >>>> >>>> that >>>>> >>>>> they are synced and a page wont be altered by 2 threads at the same >>>>> time\ >>>>> >>>>> But how does a none sticky configuration work? Will the second request >>>>> go >>>> >>>> to >>>>> >>>>> another server? And just alter there the page state? >>>>> It can do that because our sync block doesnt work then ofcourse. >>>>> >>>>> But if this happens, what happens after that? now the same page >>>>> instance >>>> >>>> is >>>>> >>>>> altered on both places.. Which one takes precedence ? >>>>> Because it is impossible for the container to merge the objects. So it >>>>> should take 1 or the other.. >>>>> So the first click that took longer then the second click will >>>>> overwrite >>>> >>>> the >>>>> >>>>> second click page. But that now overwritten page is now shown to the >>>>> user >>>>> So if you then click on something that was on the page of the second >>>> >>>> click >>>>> >>>>> but wasnt on the page of the first click. Then you will get an page >>>> >>>> expired >>>>> >>>>> or something like that.. >>>>> >>>>> maybe somehow containers do some synching across concurrent request of >>>>> 1 >>>>> session (hopefully the will send them to the same server) >>>>> But i dont know. Synching over servers is very expensive.. then the >>>>> whole >>>>> usage of having none sticky sessions is completely gone in my eyes. >>>>> >>>>> johan >>>>> >>>>> On Tue, Mar 10, 2009 at 10:49, Martin Grotzke >>>>> <[email protected]>wrote: >>>>> >>>>>> On Mon, 2009-03-09 at 22:54 -0700, Victor Igumnov wrote: >>>>>>> >>>>>>> Even if you have the memcached store in place, wicket still requires >>>>>>> session affinity. Wicket buffers redirect responses locally so the >>>>>>> client needs to go to the same server twice or the client will >>>> >>>> receive >>>>>>> >>>>>>> an expired session. Wicket is a stateful framework, session affinity >>>>>>> is a must. >>>>>> >>>>>> Are there other things (besides the buffered response when doing a >>>>>> redirect-after-post with the REDIRECT_TO_BUFFER setting) that require >>>>>> sticky sessions? >>>>>> >>>>>> We'd like to use wicket in a stateless mode and defer session creation >>>>>> as long as it's possible for a user. Even if wicket is made with a >>>>>> statefull programming model in mind we think there are still many >>>>>> advantages over other (non-component-based) frameworks. Also we need a >>>>>> dynamic structure which would be rather hard to realize/simulate with >>>>>> some other component oriented frameworks ;) >>>>>> >>>>>> Cheers, >>>>>> Martin >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> On Mar 9, 2009, at 7:03 AM, Martin Grotzke wrote: >>>>>>> >>>>>>>> On Mon, 2009-03-09 at 13:07 +0100, Martijn Dashorst wrote: >>>>>>>>> >>>>>>>>> Starts to sound like a form of premature optimization. If you are >>>> >>>> new >>>>>>>>> >>>>>>>>> to Wicket, why do you want to implement a memcached session store? >>>>>>>>> What is the usecase? >>>>>>>> >>>>>>>> We're starting a new project (the relaunch of a big ecommerce >>>> >>>> system) >>>>>>>> >>>>>>>> and want to be able to scale out (just throw in new hardware when >>>>>>>> traffic grows). Additionally we have the requirement of session >>>>>>>> failover, both in standard operations and for deployments. >>>>>>>> >>>>>>>> We're discussing non-sticky vs. sticky sessions here and for non- >>>>>>>> sticky >>>>>>>> sessions memcached (as caching layer in addition to sessions stored >>>>>>>> in a >>>>>>>> database) is a good candidate, as you don't replicate the changed >>>>>>>> session to all other nodes, but only to the primary node for this >>>>>>>> session id. This is an important aspect for beeing able to scale >>>> >>>> out. >>>>>>>> >>>>>>>> Concerning non-sticky/sticky/memcached/whatever we're not decided >>>> >>>> yet, >>>>>>>> >>>>>>>> still running in evaluation mode :) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Martin >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Martijn >>>>>>>>> >>>>>>>>> On Mon, Mar 9, 2009 at 9:56 AM, Martin Grotzke >>>>>>>>> <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> On Sun, 2009-03-08 at 16:56 -0700, Victor Igumnov wrote: >>>>>>>>>>> >>>>>>>>>>> I wrote a memcached session manager store for jetty, that our >>>>>>>>>>> wicket >>>>>>>>>>> app utilizes. Works well, except I can't open source it, >>>>>>>>>>> since it was created on the company's dime ;-( >>>>>>>>>> >>>>>>>>>> Well, most interesting things are not so simple to realize that >>>>>>>>>> one can >>>>>>>>>> do it in its spare time. But the good point is that we can do >>>> >>>> such >>>>>>>>>> >>>>>>>>>> interesting things in our job :) >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Here is my opinion on memcached as a session store. >>>>>>>>>>> >>>>>>>>>>> Memcached will not work well as a wicket session store, due to >>>> >>>> 1mb >>>>>>>>>>> >>>>>>>>>>> size limits. >>>>>>>>>> >>>>>>>>>> Good to know, I wasn't aware of this restriction (I still need to >>>>>>>>>> read >>>>>>>>>> more about this for details). So one is forced to handle >>>> >>>> resources >>>>>>>>>> >>>>>>>>>> eating much memory (e.g. fileupload) not via session, which is >>>> >>>> the >>>>>>>>>> >>>>>>>>>> case >>>>>>>>>> even without this 1 mb size limit :) >>>>>>>>>> >>>>>>>>>> Do you have a case where this limit is important especially for >>>>>>>>>> wicket? >>>>>>>>>> >>>>>>>>>>> You honestly don't want to serialize anything past 100kb >>>>>>>>>>> in size due to performance reasons. >>>>>>>>>> >>>>>>>>>> Right. >>>>>>>>>> >>>>>>>>>>> That said, It works best if you >>>>>>>>>>> use memcached as a container httpsessionstore with the wicket >>>>>>>>>>> secondlevelcache diskpagestore. The only thing you need to >>>>>>>>>>> serialize >>>>>>>>>>> is the last pagemap which should only be 50kb in size max. You >>>>>>>>>>> still >>>>>>>>>>> get fail over since the last page map is distributed. >>>>>>>>>> >>>>>>>>>> And I have to read about page maps (I'm really new to wicket as >>>> >>>> you >>>>>>>>>> >>>>>>>>>> see :)). AFAIK page maps store a configurable numer of versioned >>>>>>>>>> pages >>>>>>>>>> for back-button support and versioned pages. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> One thing you need to be careful with is not referencing >>>> >>>> anything >>>>>>>>>>> >>>>>>>>>>> that >>>>>>>>>>> got stored on disk from your active pagemap, it will spiral into >>>> >>>> a >>>>>>>>>>> >>>>>>>>>>> stack overflow. >>>>>>>>>>> >>>>>>>>>>> https://issues.apache.org/jira/browse/WICKET-2138 >>>>>>>>>> >>>>>>>>>> Thanx! We would need to setup tests to be sure that this won't >>>>>>>>>> happen. >>>>>>>>>> >>>>>>>>>> Thanx for your input, >>>>>>>>>> cheers, >>>>>>>>>> Martin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -Victor >>>>>>>>>>> >>>>>>>>>>> On Mar 8, 2009, at 3:25 PM, Martijn Dashorst wrote: >>>>>>>>>>> >>>>>>>>>>>> You can check the TIM integration work from the Terracotta >>>> >>>> guys. >>>>>>>>>>>> >>>>>>>>>>>> That >>>>>>>>>>>> should make things easier, and you could even try it out, >>>> >>>> perhaps >>>>>>>>>>>> >>>>>>>>>>>> saving a memcached implementation completely :) >>>>>>>>>>>> >>>>>>>>>>>> Martijn >>>>>>>>>>>> >>>>>>>>>>>> On Sun, Mar 8, 2009 at 11:01 PM, Martin Grotzke >>>>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> we're just thinking about a session store using memcached. I >>>> >>>> just >>>>>>>>>>>>> >>>>>>>>>>>>> want >>>>>>>>>>>>> to ask if somebody already implemented this (and wants to >>>> >>>> share) >>>>>>>>>>>>> >>>>>>>>>>>>> before >>>>>>>>>>>>> we implement this. >>>>>>>>>>>>> >>>>>>>>>>>>> Btw, is there some documentation about ISessionStore >>>> >>>> semantics, >>>>>>>>>>>>> >>>>>>>>>>>>> in >>>>>>>>>>>>> addition to javadocs? I would be interested in the order in >>>>>>>>>>>>> which the >>>>>>>>>>>>> different methods would be invoked. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanx && cheers, >>>>>>>>>>>>> Martin >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Become a Wicket expert, learn from the best: >>>>>> >>>>>> http://wicketinaction.com >>>>>>>>>>>> >>>>>>>>>>>> Apache Wicket 1.3.5 is released >>>>>>>>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>> >>>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
