ADF client side state saving is faster and ligther. You can give that a shot.
On 1/31/07, Gattu, Praveen <[EMAIL PROTECTED]> wrote:
Ok I tried using the compression flag with the client side save state and it cut down the page size by 2/3. That satisfies my needs for now. However is there a compression ratio parameter that I could tweak. I couldn't find any from the documentation. Also I was reading some blogs from Jacob Hookom, about stateless JSF session, does anyone know whats the status of this. http://weblogs.java.net/blog/jhook/archive/2006/01/experiment_goin_1.html -Praveen -----Original Message----- From: Simon Kitching [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 30, 2007 11:16 AM To: MyFaces Discussion Subject: Re: Jsf_tree_64 Gattu, Praveen wrote: > Hi Folks - We are using the myfaces(1.1.5 snapshot). I got couple of > questions regarding the state save. So far we were using the server > side save state to reduce the page size of our pages, but noticed that > with this approach, our app cannot work behind a load balancer. We are > using Tomcat as webserver, and we donot intend to use tomcat > clustering. In order to avoid this we switched to client side save > state. Although this solved the load balancing issue, we saw the page > sizes increase by 10-15x. A page with server side save state with a > size of 18kb, now measures ~300kbyes with client side save state. > > I noticed that the framework is using "jsf_tree_64" hidden field for > all the command links, to store some form of data. What is this field > used for in the framework? Saving the current component tree. It needs to be stored somewhere, and if you don't want it in the http session ("server-side state") then it has to be stored in the form ("client-side state"). Is there a way to avoid this hidden field, without > using the server side save state? Nope. Are there any other approaches I > should be looking to solve both load balancing and low page size? Perhaps a "sticky load balancer", ie one that is http-session-aware and therefore directs all requests for a specific session to a single tomcat instance? I can't see any other alternatives, if you're opposed to clustering; the tomcat instance that handles the submit must have the component tree data available, and the only options are (a) in the http session, or (b) embedded in the posted data. Regards, Simon
-- When I tell the truth, it is not for the sake of convincing those who do not know it, but for the sake of defending those that do
