did you see this on the wiki http://wiki.apache.org/myfaces/Performanceregards...On 5/19/06,
iSquareOne LLC <[EMAIL PROTECTED]> wrote:
Hi, all, This is a bit tricky. We have two applications - one is built on pure JSP and the other one is built on JSF. We found the JSF application performance i
Performance measurements have shown that plain server side state
saving (without serialization and without compressing state) comes
with the best values.
Also usage of StreamingAddResource brings about 20% performance improvements.
Apart from that, using JSP as page description slows down. Facel
Hi!
> We have the technical requirement to stay with JSPs. :(
Well, we use JSP to describe the JSF view too - we slowly convert our
application from JSP to JSF (so we have both JSP embedded in JSF and
pure JSF), and I cant say that the performance it that worse.
> But there must be a way to put JS
Hi, Gerald
Could you advise where I can find t:document TLD ? Is it in tomahawk
extension inside myfaces1,1/1.1.1 ?
I cannot find this tag in documentation.
Thanks,
yasushi
Gerald Müllan wrote:
Performance measurements have shown that plain server side state
saving (without serialization a
Discussion
Subject: Re: How to improve JSF performance?
Hi, Gerald
Could you advise where I can find t:document TLD ? Is it in tomahawk
extension inside myfaces1,1/1.1.1 ?
I cannot find this tag in documentation.
Thanks,
yasushi
Gerald Müllan wrote:
> Performance measurements have shown that pl
upgrading to 1.1.3, that will be great.
thanks,
yasushi
-Original Message-
From: Yasushi Okubo [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 19, 2006 2:05 PM
To: MyFaces Discussion
Subject: Re: How to improve JSF performance?
Hi, Gerald
Could you advise where I can find t:document TLD
Wow!
I just applied these changes to the test server running on my workstation.
Performance is significantly better.
Thx!
Mike
--- Murat Hazer <[EMAIL PROTECTED]> wrote:
> did you see this on the wiki http://wiki.apache.org/myfaces/Performance
>
> regards...
>
> On 5/19/06, iSquareOne LLC <
mailto:[EMAIL PROTECTED]
Sent: Friday, May 19, 2006 2:05 PM
To: MyFaces Discussion
Subject: Re: How to improve JSF performance?
Hi, Gerald
Could you advise where I can find t:document TLD ? Is it in tomahawk
extension inside myfaces1,1/1.1.1 ?
I cannot find this tag in documentation.
Thanks,
y
ely so.>> If I can use this tag for myfaces1.1.1, that will be great. But I cannot> find a way to do so now. If you can advise me how I can use
it without> upgrading to 1.1.3, that will be great.>> thanks,> yasushi>>>>>>> -Original Message--
e me how I can use
it without> upgrading to 1.1.3, that will be great.>> thanks,> yasushi>>>>>>> -----Original Message-> From: Yasushi Okubo [mailto:
[EMAIL PROTECTED]]> Sent: Friday, May 19, 2006 2:05 PM> To: MyFaces Discussion> Subject: Re: Ho
Hi.
My environment: MyFaces 1.1.3 + Tomahawk 1.1.2 + Facelet 1.0.4 +
javax.faces.STATE_SAVING_METHOD =client
I'm testing StreamingAddResource as told in Wiki to get some performance
improvements.
Everything worked ok after modifying jsp files and web.xml
configuration. Except that time to
does not recognize
this
> > tag. I only see this tag for tomahawk 1.1.3 core when I googled, but not
> > sure if truely so.
> >
> > If I can use this tag for myfaces1.1.1, that will be great. But I cannot
> > find a way to do so now. If you can advise me how I can use
y in tomahawk extension.> > > Then, when I tried to use this t:document tag, it does not recognize
> this> > > tag. I only see this tag for tomahawk 1.1.3 core when I googled, but not> > > sure if truely so.> > >> > > If I can use this tag for myface
Hi.
Aleksei, how (and where) can the "lastModified" be set manually?
Directly somewhere in the jar?
See
tomahawk-${version}.jar/org/apache/myfaces/renderkit/html/util/AddResources.properties.
Unpack the jar, correct the file and pack it back.
I have tested earlier the server side and I know
ar myfaces-api.jar myfaces-impl.jar
> > > > NOTICE.txt sandbox.jar tlddoc tomahawk.jar
> > > >
> > > > Then, I opened the documentaion uder tlddoc, I do not see any
t:document
> > > > entry in tomahawk extension.
> > > > Then, when I tried to use
Mario Ivankovits schrieb:
> Hi!
>> We have the technical requirement to stay with JSPs. :(
> Well, we use JSP to describe the JSF view too - we slowly convert our
> application from JSP to JSF (so we have both JSP embedded in JSF and
> pure JSF), and I cant say that the performance it that worse.
>
Hi!
>> Well, we use JSP to describe the JSF view too - we slowly convert our
>> application from JSP to JSF (so we have both JSP embedded in JSF and
>> pure JSF), and I cant say that the performance it that worse.
>>
> It can be that worse, actually, client side state saving is a huge
> burden
Mario Ivankovits wrote:
It can be that worse, actually, client side state saving is a huge
burden, but it does not have to be, the correct state saving strategy
(server side) can give a huge push.
Oh, well, for sure, and I dont know why one would like to use client
side state saving in real l
Unfortunately client side state is the only way to get multiple
component trees to not conflict (IFRAME, popup windows, user has
multiple windows open, etc). I am using server state and as a result,
I cannot use some of these techniques (like the jenia4faces dialog).
If that was fixed (apparently
Hi!
> Unfortunately client side state is the only way to get multiple
> component trees to not conflict (IFRAME, popup windows, user has
> multiple windows open, etc).
Is this still the case?
MyFaces holds multiple versions per view - so this should be no longer a
problem.
For sure, only a number o
Hi!
> Being slow is better than running out of memory.
Is memory really a factor here? The view isnt that huge, is it?
So even if the view is 5k big and you store the last 20 per user and
expect 1000 concurrent users you'll end with 100Mb view data on the
server - you will have many other problems
On 5/22/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
>> Well, we use JSP to describe the JSF view too - we slowly convert our
>> application from JSP to JSF (so we have both JSP embedded in JSF and
>> pure JSF), and I cant say that the performance it that worse.
>>
> It can be that worse, actu
Hi!
> I only use client-side state saving in my applications.
>
> client-side state saving eliminates the back button problem, and it
> can survive the death of the application server transparently.
> There's also no issues with session timeouts.
Ok, I understand, in the past I also used client-sid
On 5/22/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Ok, I understand, in the past I also used client-side state saving, but
things happening lately showed me that in the end I cant stick with it.
Transparent persistence (hibernate) - "application transaction" - to
tell only the headlines ;-)
StreamingAddResource doesn't let me implement error page redirection. It flushes response buffer and if error happens after thatyou can't forward to the error page. It seems the obly workable solution for serious application is server side state with no serialization.
On 5/22/06, Aleksei Valikov <[
25 matches
Mail list logo
