You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Andy Schwartz <an...@gmail.com> on 2011/10/13 22:13:57 UTC
Web Framework Performance Comparision
Gang -
I recently got wind of the following web framework performance talk
that was presented at JavaOne:
https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf
I did not attend, but based on the slides it looks like the presenters
did an very thorough/systematic job of evaluating
performance/scalability for a handful of web frameworks, including
JSF. (I also have to say that they slides are simply beautiful -
wow!)
I wanted to call attention to this talk because I am concerned about
one aspect of the results. Looking at slide #73, it seems that the
presenters are seeing significant overhead in the MyFaces test runs
(ie. vs. equivalent runs in Mojarra). I don't have any details other
than the $ numbers included in the slides, but seems quite possible
that there is some low-hanging fruit waiting to be picked (or
optimized).
Is anyone acquainted with the presenters? Perhaps it would be
worthwhile to contact them to see whether it would be possible to take
a closer look at the test case?
Andy
Re: Web Framework Performance Comparision
Posted by Werner Punz <we...@gmail.com>.
yes the famous mojarra.ab function, in reality it is a thin wrapper
over jsf.ajax and probably what we have with our oamsubmit call.
(I have never looked into that function)
Werner
Am 10/14/11 7:28 AM, schrieb Leonardo Uribe:
> Hi
>
> Note in the latest code, another performance improvement was done over
> generated ids (MYFACES-3330), reducing the final size of the generated
> html. Doing some tests, I notice that mojarra use a "simplified" form
> to call methods on the standard jsf api, calling first a function on
> "mojarra" namespaces and then inside that function there is the real
> call.
>
> Leonardo
>
> 2011/10/13 Werner Punz<we...@gmail.com>:
>> Just to add some numbers, the rendered html seems to be roughly 10-15% more
>> compact on Mojarra. We did some work already by replacing our inline
>> oamsubmit by an externalized call which was the biggest issue, but there
>> seems to be still room for improvement.
>>
>>
>> Werner
>>
>>
>> Am 10/14/11 1:21 AM, schrieb Werner Punz:
>>>
>>> Actually now that I have some tests at hand, I just
>>> coded some profiling code in.
>>>
>>> Here are some numbers for tests which are running on both impls.
>>> The tests have been performed at the Production stage on both impls.
>>> The testing environments where myfaces 2.1.4-SNAPSHOT against Mojarra
>>> 2.1.2. Both running on the same testing framework. The tests usually are
>>> done from the begin of the testgroup til the end they count more or less
>>> server and client performance and testing time. But the differences give
>>> a good indication about the corresponding speeds.
>>>
>>> The machine which ran the tests was a macbook pro core2duo with 8 gig
>>> ram and the tests were run on an ssd. So IO impact is down to a bare
>>> minimum here. The tests themselves do not do any excessive disk io.
>>>
>>>
>>> JSF Protocol Tests
>>> MyFaces: Time for test in ms: 239
>>> Mojarra: Time for test in ms: 207
>>> This is a servlet based test
>>>
>>> Testgroup: Full Body Replacement
>>> MyFaces:Time for test in ms: 42
>>> Mojarra:Time for test in ms: 35
>>> This is a servlet based test
>>>
>>> Testgroup: Multi form situation
>>> MyFaces: Time for test in ms: 4134
>>> Mojarra:Time for test in ms: 4426
>>> This is a jsf related test
>>>
>>> Testgroup: Testing for decorated api calls
>>> MyFaces: Time for test in ms: 24
>>> Mojarra: Time for test in ms: 34
>>>
>>> Testgroup: Double Eval Detection:
>>> MyFaces: Time for test in ms: 2047
>>> Mojarra: Time for test in ms: 2060
>>>
>>> Testgroup: Table Test, replacement of table elements
>>> MyFaces: Time for test in ms: 7289
>>> Mojarra: Time for test in ms: 9229
>>>
>>> Testgroup: Partial Page Rendering Nav Case
>>> MyFaces: Time for test in ms: 2168
>>> Mojarra: Time for test in ms: 2308
>>>
>>> Testgroup: MyFaces Event Lifecycle test
>>> MyFaces: Time for test in ms: 130
>>> Mojarra: Time for test in ms: 131
>>>
>>> So what we have here is that in most cases especially in all jsf related
>>> tests myfaces is a little bit faster than Mojarra.
>>> Our scripts seem to be roughly 10% slower, however.But i also still have
>>> some self induced overhead in the test framework which might count for
>>> roughly 2-3% which is not active in Mojarra and we deal with corner
>>> cases mojarra does not cover.
>>>
>>> The difference probably is on IE6 even more, because I am dealing more
>>> cleanly with the broken garbage collector of IE6 in my code which causes
>>> also some performance overhead.
>>>
>>> Also have in mind, we deal with more functonality and more code and also
>>> we have some fixes in which Mojarra yet has to add.
>>> Under normal JSF circumstances by now the server seems to make up for
>>> the speed difference (normally 95% of the time is spent on the server
>>> anyway) by being roughly 10-15% faster than Mojarra by now.
>>>
>>> If we turn to development the picture turns a little bit with myfaces
>>> being slower in some tests (I will give the performance numbers tomorrow).
>>>
>>> So my conclusion is that they probably have tested against an old Impl
>>> here.
>>>
>>> I will commit the code with the profiling data tomorrow once I have
>>> resolved the problem of the testing framework interfering with myfaces
>>> on production level performancewise.
>>>
>>>
>>>
>>> Werner
>>>
>>> Am 10/13/11 11:20 PM, schrieb Werner Punz:
>>>>
>>>> Yes from what i gather one of the issues they had in the slides was the
>>>> overall page size. The question there is more along the lines what did
>>>> they count, just the rendered code, or also the includes.
>>>>
>>>> I can help to reduce the size on the JSF.js side. We have some code
>>>> which is not directly active for JSF 2.1 and will very likely become
>>>> part of jsf 2.2 or 2.3. it can be used today already by adding config
>>>> params, Also we have some internationalization
>>>> of the internal error messages.
>>>>
>>>> This code could be externalized into an addition js file for people who
>>>> need it. I think we might save around 20Kbytes that way.
>>>>
>>>> I personally did not think that it was necessary due to the fact that
>>>> the js files usually are gzipped while still bigger than mojarra we
>>>> after gzipping the file talk about sizes of 10-30k etc...
>>>>
>>>> In the end externalizing that code would have caused more burden on the
>>>> users than it would have helped. But given that mojarra just implements
>>>> the raw api and nothing else and does not take some corner conditions
>>>> into consideration and has no browser optimizations they are
>>>> significantly smaller in their jsf.js file and if our size is a problem
>>>> we can reduce it.
>>>>
>>>>
>>>>
>>>>
>>>> Werner
>>>>
>>>>
>>>> Am 10/13/11 11:07 PM, schrieb Leonardo Uribe:
>>>>>
>>>>> Hi
>>>>>
>>>>> I believe probably we already did that. The biggest bottleneck we had
>>>>> was that renderers did many calls to map.get(). Mojarra had an
>>>>> optimization in this part, but MyFaces do not until 2.0.9/2.1.3, so I
>>>>> suppose with the latest code we have better numbers.
>>>>>
>>>>> regards,
>>>>>
>>>>> Leonardo Uribe
>>>>>
>>>>> 2011/10/13 Werner Punz<we...@gmail.com>:
>>>>>>
>>>>>> I would be interested as well, especially regarding their test
>>>>>> setup, we
>>>>>> basically doubled for instance our ajax performance between 2.0.4 and
>>>>>> the
>>>>>> current state of affairs.
>>>>>>
>>>>>> So it might be interesting to see what testsetup they were using.
>>>>>> From a pure memory point of view we of course have a higher load on the
>>>>>> browser because our ajax implementation deals with things mojarra
>>>>>> does not
>>>>>> and also has an oo layer underneath. But I added browser specific
>>>>>> optimisations so on modern browsers we should be slightly faster than
>>>>>> mojarra in raw ajax processing (at least my personal tests resembled
>>>>>> that
>>>>>> when I did the profiling), while mojarra is sligtly ahead on Firefox
>>>>>> 3.5 and
>>>>>> IE6 and 7.
>>>>>>
>>>>>> Just giving the numbers unfortunately does not help to see where their
>>>>>> bottleneck was they discovered.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Werner
>>>>>>
>>>>>>
>>>>>> Am 10/13/11 10:13 PM, schrieb Andy Schwartz:
>>>>>>>
>>>>>>> Gang -
>>>>>>>
>>>>>>> I recently got wind of the following web framework performance talk
>>>>>>> that was presented at JavaOne:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I did not attend, but based on the slides it looks like the presenters
>>>>>>> did an very thorough/systematic job of evaluating
>>>>>>> performance/scalability for a handful of web frameworks, including
>>>>>>> JSF. (I also have to say that they slides are simply beautiful -
>>>>>>> wow!)
>>>>>>>
>>>>>>> I wanted to call attention to this talk because I am concerned about
>>>>>>> one aspect of the results. Looking at slide #73, it seems that the
>>>>>>> presenters are seeing significant overhead in the MyFaces test runs
>>>>>>> (ie. vs. equivalent runs in Mojarra). I don't have any details other
>>>>>>> than the $ numbers included in the slides, but seems quite possible
>>>>>>> that there is some low-hanging fruit waiting to be picked (or
>>>>>>> optimized).
>>>>>>>
>>>>>>> Is anyone acquainted with the presenters? Perhaps it would be
>>>>>>> worthwhile to contact them to see whether it would be possible to take
>>>>>>> a closer look at the test case?
>>>>>>>
>>>>>>> Andy
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
Re: Web Framework Performance Comparision
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
Note in the latest code, another performance improvement was done over
generated ids (MYFACES-3330), reducing the final size of the generated
html. Doing some tests, I notice that mojarra use a "simplified" form
to call methods on the standard jsf api, calling first a function on
"mojarra" namespaces and then inside that function there is the real
call.
Leonardo
2011/10/13 Werner Punz <we...@gmail.com>:
> Just to add some numbers, the rendered html seems to be roughly 10-15% more
> compact on Mojarra. We did some work already by replacing our inline
> oamsubmit by an externalized call which was the biggest issue, but there
> seems to be still room for improvement.
>
>
> Werner
>
>
> Am 10/14/11 1:21 AM, schrieb Werner Punz:
>>
>> Actually now that I have some tests at hand, I just
>> coded some profiling code in.
>>
>> Here are some numbers for tests which are running on both impls.
>> The tests have been performed at the Production stage on both impls.
>> The testing environments where myfaces 2.1.4-SNAPSHOT against Mojarra
>> 2.1.2. Both running on the same testing framework. The tests usually are
>> done from the begin of the testgroup til the end they count more or less
>> server and client performance and testing time. But the differences give
>> a good indication about the corresponding speeds.
>>
>> The machine which ran the tests was a macbook pro core2duo with 8 gig
>> ram and the tests were run on an ssd. So IO impact is down to a bare
>> minimum here. The tests themselves do not do any excessive disk io.
>>
>>
>> JSF Protocol Tests
>> MyFaces: Time for test in ms: 239
>> Mojarra: Time for test in ms: 207
>> This is a servlet based test
>>
>> Testgroup: Full Body Replacement
>> MyFaces:Time for test in ms: 42
>> Mojarra:Time for test in ms: 35
>> This is a servlet based test
>>
>> Testgroup: Multi form situation
>> MyFaces: Time for test in ms: 4134
>> Mojarra:Time for test in ms: 4426
>> This is a jsf related test
>>
>> Testgroup: Testing for decorated api calls
>> MyFaces: Time for test in ms: 24
>> Mojarra: Time for test in ms: 34
>>
>> Testgroup: Double Eval Detection:
>> MyFaces: Time for test in ms: 2047
>> Mojarra: Time for test in ms: 2060
>>
>> Testgroup: Table Test, replacement of table elements
>> MyFaces: Time for test in ms: 7289
>> Mojarra: Time for test in ms: 9229
>>
>> Testgroup: Partial Page Rendering Nav Case
>> MyFaces: Time for test in ms: 2168
>> Mojarra: Time for test in ms: 2308
>>
>> Testgroup: MyFaces Event Lifecycle test
>> MyFaces: Time for test in ms: 130
>> Mojarra: Time for test in ms: 131
>>
>> So what we have here is that in most cases especially in all jsf related
>> tests myfaces is a little bit faster than Mojarra.
>> Our scripts seem to be roughly 10% slower, however.But i also still have
>> some self induced overhead in the test framework which might count for
>> roughly 2-3% which is not active in Mojarra and we deal with corner
>> cases mojarra does not cover.
>>
>> The difference probably is on IE6 even more, because I am dealing more
>> cleanly with the broken garbage collector of IE6 in my code which causes
>> also some performance overhead.
>>
>> Also have in mind, we deal with more functonality and more code and also
>> we have some fixes in which Mojarra yet has to add.
>> Under normal JSF circumstances by now the server seems to make up for
>> the speed difference (normally 95% of the time is spent on the server
>> anyway) by being roughly 10-15% faster than Mojarra by now.
>>
>> If we turn to development the picture turns a little bit with myfaces
>> being slower in some tests (I will give the performance numbers tomorrow).
>>
>> So my conclusion is that they probably have tested against an old Impl
>> here.
>>
>> I will commit the code with the profiling data tomorrow once I have
>> resolved the problem of the testing framework interfering with myfaces
>> on production level performancewise.
>>
>>
>>
>> Werner
>>
>> Am 10/13/11 11:20 PM, schrieb Werner Punz:
>>>
>>> Yes from what i gather one of the issues they had in the slides was the
>>> overall page size. The question there is more along the lines what did
>>> they count, just the rendered code, or also the includes.
>>>
>>> I can help to reduce the size on the JSF.js side. We have some code
>>> which is not directly active for JSF 2.1 and will very likely become
>>> part of jsf 2.2 or 2.3. it can be used today already by adding config
>>> params, Also we have some internationalization
>>> of the internal error messages.
>>>
>>> This code could be externalized into an addition js file for people who
>>> need it. I think we might save around 20Kbytes that way.
>>>
>>> I personally did not think that it was necessary due to the fact that
>>> the js files usually are gzipped while still bigger than mojarra we
>>> after gzipping the file talk about sizes of 10-30k etc...
>>>
>>> In the end externalizing that code would have caused more burden on the
>>> users than it would have helped. But given that mojarra just implements
>>> the raw api and nothing else and does not take some corner conditions
>>> into consideration and has no browser optimizations they are
>>> significantly smaller in their jsf.js file and if our size is a problem
>>> we can reduce it.
>>>
>>>
>>>
>>>
>>> Werner
>>>
>>>
>>> Am 10/13/11 11:07 PM, schrieb Leonardo Uribe:
>>>>
>>>> Hi
>>>>
>>>> I believe probably we already did that. The biggest bottleneck we had
>>>> was that renderers did many calls to map.get(). Mojarra had an
>>>> optimization in this part, but MyFaces do not until 2.0.9/2.1.3, so I
>>>> suppose with the latest code we have better numbers.
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>> 2011/10/13 Werner Punz<we...@gmail.com>:
>>>>>
>>>>> I would be interested as well, especially regarding their test
>>>>> setup, we
>>>>> basically doubled for instance our ajax performance between 2.0.4 and
>>>>> the
>>>>> current state of affairs.
>>>>>
>>>>> So it might be interesting to see what testsetup they were using.
>>>>> From a pure memory point of view we of course have a higher load on the
>>>>> browser because our ajax implementation deals with things mojarra
>>>>> does not
>>>>> and also has an oo layer underneath. But I added browser specific
>>>>> optimisations so on modern browsers we should be slightly faster than
>>>>> mojarra in raw ajax processing (at least my personal tests resembled
>>>>> that
>>>>> when I did the profiling), while mojarra is sligtly ahead on Firefox
>>>>> 3.5 and
>>>>> IE6 and 7.
>>>>>
>>>>> Just giving the numbers unfortunately does not help to see where their
>>>>> bottleneck was they discovered.
>>>>>
>>>>>
>>>>>
>>>>> Werner
>>>>>
>>>>>
>>>>> Am 10/13/11 10:13 PM, schrieb Andy Schwartz:
>>>>>>
>>>>>> Gang -
>>>>>>
>>>>>> I recently got wind of the following web framework performance talk
>>>>>> that was presented at JavaOne:
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf
>>>>>>
>>>>>>
>>>>>>
>>>>>> I did not attend, but based on the slides it looks like the presenters
>>>>>> did an very thorough/systematic job of evaluating
>>>>>> performance/scalability for a handful of web frameworks, including
>>>>>> JSF. (I also have to say that they slides are simply beautiful -
>>>>>> wow!)
>>>>>>
>>>>>> I wanted to call attention to this talk because I am concerned about
>>>>>> one aspect of the results. Looking at slide #73, it seems that the
>>>>>> presenters are seeing significant overhead in the MyFaces test runs
>>>>>> (ie. vs. equivalent runs in Mojarra). I don't have any details other
>>>>>> than the $ numbers included in the slides, but seems quite possible
>>>>>> that there is some low-hanging fruit waiting to be picked (or
>>>>>> optimized).
>>>>>>
>>>>>> Is anyone acquainted with the presenters? Perhaps it would be
>>>>>> worthwhile to contact them to see whether it would be possible to take
>>>>>> a closer look at the test case?
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
Re: Web Framework Performance Comparision
Posted by Werner Punz <we...@gmail.com>.
Just to add some numbers, the rendered html seems to be roughly 10-15%
more compact on Mojarra. We did some work already by replacing our
inline oamsubmit by an externalized call which was the biggest issue,
but there seems to be still room for improvement.
Werner
Am 10/14/11 1:21 AM, schrieb Werner Punz:
> Actually now that I have some tests at hand, I just
> coded some profiling code in.
>
> Here are some numbers for tests which are running on both impls.
> The tests have been performed at the Production stage on both impls.
> The testing environments where myfaces 2.1.4-SNAPSHOT against Mojarra
> 2.1.2. Both running on the same testing framework. The tests usually are
> done from the begin of the testgroup til the end they count more or less
> server and client performance and testing time. But the differences give
> a good indication about the corresponding speeds.
>
> The machine which ran the tests was a macbook pro core2duo with 8 gig
> ram and the tests were run on an ssd. So IO impact is down to a bare
> minimum here. The tests themselves do not do any excessive disk io.
>
>
> JSF Protocol Tests
> MyFaces: Time for test in ms: 239
> Mojarra: Time for test in ms: 207
> This is a servlet based test
>
> Testgroup: Full Body Replacement
> MyFaces:Time for test in ms: 42
> Mojarra:Time for test in ms: 35
> This is a servlet based test
>
> Testgroup: Multi form situation
> MyFaces: Time for test in ms: 4134
> Mojarra:Time for test in ms: 4426
> This is a jsf related test
>
> Testgroup: Testing for decorated api calls
> MyFaces: Time for test in ms: 24
> Mojarra: Time for test in ms: 34
>
> Testgroup: Double Eval Detection:
> MyFaces: Time for test in ms: 2047
> Mojarra: Time for test in ms: 2060
>
> Testgroup: Table Test, replacement of table elements
> MyFaces: Time for test in ms: 7289
> Mojarra: Time for test in ms: 9229
>
> Testgroup: Partial Page Rendering Nav Case
> MyFaces: Time for test in ms: 2168
> Mojarra: Time for test in ms: 2308
>
> Testgroup: MyFaces Event Lifecycle test
> MyFaces: Time for test in ms: 130
> Mojarra: Time for test in ms: 131
>
> So what we have here is that in most cases especially in all jsf related
> tests myfaces is a little bit faster than Mojarra.
> Our scripts seem to be roughly 10% slower, however.But i also still have
> some self induced overhead in the test framework which might count for
> roughly 2-3% which is not active in Mojarra and we deal with corner
> cases mojarra does not cover.
>
> The difference probably is on IE6 even more, because I am dealing more
> cleanly with the broken garbage collector of IE6 in my code which causes
> also some performance overhead.
>
> Also have in mind, we deal with more functonality and more code and also
> we have some fixes in which Mojarra yet has to add.
> Under normal JSF circumstances by now the server seems to make up for
> the speed difference (normally 95% of the time is spent on the server
> anyway) by being roughly 10-15% faster than Mojarra by now.
>
> If we turn to development the picture turns a little bit with myfaces
> being slower in some tests (I will give the performance numbers tomorrow).
>
> So my conclusion is that they probably have tested against an old Impl
> here.
>
> I will commit the code with the profiling data tomorrow once I have
> resolved the problem of the testing framework interfering with myfaces
> on production level performancewise.
>
>
>
> Werner
>
> Am 10/13/11 11:20 PM, schrieb Werner Punz:
>> Yes from what i gather one of the issues they had in the slides was the
>> overall page size. The question there is more along the lines what did
>> they count, just the rendered code, or also the includes.
>>
>> I can help to reduce the size on the JSF.js side. We have some code
>> which is not directly active for JSF 2.1 and will very likely become
>> part of jsf 2.2 or 2.3. it can be used today already by adding config
>> params, Also we have some internationalization
>> of the internal error messages.
>>
>> This code could be externalized into an addition js file for people who
>> need it. I think we might save around 20Kbytes that way.
>>
>> I personally did not think that it was necessary due to the fact that
>> the js files usually are gzipped while still bigger than mojarra we
>> after gzipping the file talk about sizes of 10-30k etc...
>>
>> In the end externalizing that code would have caused more burden on the
>> users than it would have helped. But given that mojarra just implements
>> the raw api and nothing else and does not take some corner conditions
>> into consideration and has no browser optimizations they are
>> significantly smaller in their jsf.js file and if our size is a problem
>> we can reduce it.
>>
>>
>>
>>
>> Werner
>>
>>
>> Am 10/13/11 11:07 PM, schrieb Leonardo Uribe:
>>> Hi
>>>
>>> I believe probably we already did that. The biggest bottleneck we had
>>> was that renderers did many calls to map.get(). Mojarra had an
>>> optimization in this part, but MyFaces do not until 2.0.9/2.1.3, so I
>>> suppose with the latest code we have better numbers.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2011/10/13 Werner Punz<we...@gmail.com>:
>>>> I would be interested as well, especially regarding their test
>>>> setup, we
>>>> basically doubled for instance our ajax performance between 2.0.4 and
>>>> the
>>>> current state of affairs.
>>>>
>>>> So it might be interesting to see what testsetup they were using.
>>>> From a pure memory point of view we of course have a higher load on the
>>>> browser because our ajax implementation deals with things mojarra
>>>> does not
>>>> and also has an oo layer underneath. But I added browser specific
>>>> optimisations so on modern browsers we should be slightly faster than
>>>> mojarra in raw ajax processing (at least my personal tests resembled
>>>> that
>>>> when I did the profiling), while mojarra is sligtly ahead on Firefox
>>>> 3.5 and
>>>> IE6 and 7.
>>>>
>>>> Just giving the numbers unfortunately does not help to see where their
>>>> bottleneck was they discovered.
>>>>
>>>>
>>>>
>>>> Werner
>>>>
>>>>
>>>> Am 10/13/11 10:13 PM, schrieb Andy Schwartz:
>>>>>
>>>>> Gang -
>>>>>
>>>>> I recently got wind of the following web framework performance talk
>>>>> that was presented at JavaOne:
>>>>>
>>>>>
>>>>> https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf
>>>>>
>>>>>
>>>>>
>>>>> I did not attend, but based on the slides it looks like the presenters
>>>>> did an very thorough/systematic job of evaluating
>>>>> performance/scalability for a handful of web frameworks, including
>>>>> JSF. (I also have to say that they slides are simply beautiful -
>>>>> wow!)
>>>>>
>>>>> I wanted to call attention to this talk because I am concerned about
>>>>> one aspect of the results. Looking at slide #73, it seems that the
>>>>> presenters are seeing significant overhead in the MyFaces test runs
>>>>> (ie. vs. equivalent runs in Mojarra). I don't have any details other
>>>>> than the $ numbers included in the slides, but seems quite possible
>>>>> that there is some low-hanging fruit waiting to be picked (or
>>>>> optimized).
>>>>>
>>>>> Is anyone acquainted with the presenters? Perhaps it would be
>>>>> worthwhile to contact them to see whether it would be possible to take
>>>>> a closer look at the test case?
>>>>>
>>>>> Andy
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>
Re: Web Framework Performance Comparision
Posted by Werner Punz <we...@gmail.com>.
Actually now that I have some tests at hand, I just
coded some profiling code in.
Here are some numbers for tests which are running on both impls.
The tests have been performed at the Production stage on both impls.
The testing environments where myfaces 2.1.4-SNAPSHOT against Mojarra
2.1.2. Both running on the same testing framework. The tests usually are
done from the begin of the testgroup til the end they count more or less
server and client performance and testing time. But the differences give
a good indication about the corresponding speeds.
The machine which ran the tests was a macbook pro core2duo with 8 gig
ram and the tests were run on an ssd. So IO impact is down to a bare
minimum here. The tests themselves do not do any excessive disk io.
JSF Protocol Tests
MyFaces: Time for test in ms: 239
Mojarra: Time for test in ms: 207
This is a servlet based test
Testgroup: Full Body Replacement
MyFaces:Time for test in ms: 42
Mojarra:Time for test in ms: 35
This is a servlet based test
Testgroup: Multi form situation
MyFaces: Time for test in ms: 4134
Mojarra:Time for test in ms: 4426
This is a jsf related test
Testgroup: Testing for decorated api calls
MyFaces: Time for test in ms: 24
Mojarra: Time for test in ms: 34
Testgroup: Double Eval Detection:
MyFaces: Time for test in ms: 2047
Mojarra: Time for test in ms: 2060
Testgroup: Table Test, replacement of table elements
MyFaces: Time for test in ms: 7289
Mojarra: Time for test in ms: 9229
Testgroup: Partial Page Rendering Nav Case
MyFaces: Time for test in ms: 2168
Mojarra: Time for test in ms: 2308
Testgroup: MyFaces Event Lifecycle test
MyFaces: Time for test in ms: 130
Mojarra: Time for test in ms: 131
So what we have here is that in most cases especially in all jsf related
tests myfaces is a little bit faster than Mojarra.
Our scripts seem to be roughly 10% slower, however.But i also still have
some self induced overhead in the test framework which might count for
roughly 2-3% which is not active in Mojarra and we deal with corner
cases mojarra does not cover.
The difference probably is on IE6 even more, because I am dealing more
cleanly with the broken garbage collector of IE6 in my code which causes
also some performance overhead.
Also have in mind, we deal with more functonality and more code and also
we have some fixes in which Mojarra yet has to add.
Under normal JSF circumstances by now the server seems to make up for
the speed difference (normally 95% of the time is spent on the server
anyway) by being roughly 10-15% faster than Mojarra by now.
If we turn to development the picture turns a little bit with myfaces
being slower in some tests (I will give the performance numbers tomorrow).
So my conclusion is that they probably have tested against an old Impl
here.
I will commit the code with the profiling data tomorrow once I have
resolved the problem of the testing framework interfering with myfaces
on production level performancewise.
Werner
Am 10/13/11 11:20 PM, schrieb Werner Punz:
> Yes from what i gather one of the issues they had in the slides was the
> overall page size. The question there is more along the lines what did
> they count, just the rendered code, or also the includes.
>
> I can help to reduce the size on the JSF.js side. We have some code
> which is not directly active for JSF 2.1 and will very likely become
> part of jsf 2.2 or 2.3. it can be used today already by adding config
> params, Also we have some internationalization
> of the internal error messages.
>
> This code could be externalized into an addition js file for people who
> need it. I think we might save around 20Kbytes that way.
>
> I personally did not think that it was necessary due to the fact that
> the js files usually are gzipped while still bigger than mojarra we
> after gzipping the file talk about sizes of 10-30k etc...
>
> In the end externalizing that code would have caused more burden on the
> users than it would have helped. But given that mojarra just implements
> the raw api and nothing else and does not take some corner conditions
> into consideration and has no browser optimizations they are
> significantly smaller in their jsf.js file and if our size is a problem
> we can reduce it.
>
>
>
>
> Werner
>
>
> Am 10/13/11 11:07 PM, schrieb Leonardo Uribe:
>> Hi
>>
>> I believe probably we already did that. The biggest bottleneck we had
>> was that renderers did many calls to map.get(). Mojarra had an
>> optimization in this part, but MyFaces do not until 2.0.9/2.1.3, so I
>> suppose with the latest code we have better numbers.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2011/10/13 Werner Punz<we...@gmail.com>:
>>> I would be interested as well, especially regarding their test setup, we
>>> basically doubled for instance our ajax performance between 2.0.4 and
>>> the
>>> current state of affairs.
>>>
>>> So it might be interesting to see what testsetup they were using.
>>> From a pure memory point of view we of course have a higher load on the
>>> browser because our ajax implementation deals with things mojarra
>>> does not
>>> and also has an oo layer underneath. But I added browser specific
>>> optimisations so on modern browsers we should be slightly faster than
>>> mojarra in raw ajax processing (at least my personal tests resembled
>>> that
>>> when I did the profiling), while mojarra is sligtly ahead on Firefox
>>> 3.5 and
>>> IE6 and 7.
>>>
>>> Just giving the numbers unfortunately does not help to see where their
>>> bottleneck was they discovered.
>>>
>>>
>>>
>>> Werner
>>>
>>>
>>> Am 10/13/11 10:13 PM, schrieb Andy Schwartz:
>>>>
>>>> Gang -
>>>>
>>>> I recently got wind of the following web framework performance talk
>>>> that was presented at JavaOne:
>>>>
>>>>
>>>> https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf
>>>>
>>>>
>>>> I did not attend, but based on the slides it looks like the presenters
>>>> did an very thorough/systematic job of evaluating
>>>> performance/scalability for a handful of web frameworks, including
>>>> JSF. (I also have to say that they slides are simply beautiful -
>>>> wow!)
>>>>
>>>> I wanted to call attention to this talk because I am concerned about
>>>> one aspect of the results. Looking at slide #73, it seems that the
>>>> presenters are seeing significant overhead in the MyFaces test runs
>>>> (ie. vs. equivalent runs in Mojarra). I don't have any details other
>>>> than the $ numbers included in the slides, but seems quite possible
>>>> that there is some low-hanging fruit waiting to be picked (or
>>>> optimized).
>>>>
>>>> Is anyone acquainted with the presenters? Perhaps it would be
>>>> worthwhile to contact them to see whether it would be possible to take
>>>> a closer look at the test case?
>>>>
>>>> Andy
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: Web Framework Performance Comparision
Posted by Werner Punz <we...@gmail.com>.
Ok I got into email contact with one of the guys, first of all
here is a link to the presentation http://bit.ly/nUXMfi
I will watch it in the upcoming days and then nail them
with more questions which very likely arise.
So that we can get final conclusions about eventual hotspots we might have.
Werner
Am 10/14/11 11:13 PM, schrieb Werner Punz:
> Hi, I got an answer from one of the guys over twitter.
> They were using MyFaces 2.1.1, I am trying to find out if they used
> Development stage or Production. I also gave him the hint to try
> Myfaces 2.1.4-Snapshot.
>
> It might be interesting to see their tests revisited with 2.1.4.
>
>
> Werner
>
>
> Am 10/14/11 11:40 AM, schrieb Mark Struberg:
>> I got to similar numbers WHEN I was in ProjectStaged.Development only.
>> In this case we have our DebugPhaseListener running and lots of other
>> stuff as well.
>>
>> Once I benched with PS.Production, the numbers were pretty well.
>>
>> LieGrue,
>> strub
>>
>>
>>
>> ----- Original Message -----
>>> From: Werner Punz<we...@gmail.com>
>>> To: dev@myfaces.apache.org
>>> Cc:
>>> Sent: Thursday, October 13, 2011 11:20 PM
>>> Subject: Re: Web Framework Performance Comparision
>>>
>>> Yes from what i gather one of the issues they had in the slides was the
>>> overall page size. The question there is more along the lines what did
>>> they count, just the rendered code, or also the includes.
>>>
>>> I can help to reduce the size on the JSF.js side. We have some code
>>> which is not directly active for JSF 2.1 and will very likely become
>>> part of jsf 2.2 or 2.3. it can be used today already by adding config
>>> params, Also we have some internationalization
>>> of the internal error messages.
>>>
>>> This code could be externalized into an addition js file for people who
>>> need it. I think we might save around 20Kbytes that way.
>>>
>>> I personally did not think that it was necessary due to the fact that
>>> the js files usually are gzipped while still bigger than mojarra we
>>> after gzipping the file talk about sizes of 10-30k etc...
>>>
>>> In the end externalizing that code would have caused more burden on the
>>> users than it would have helped. But given that mojarra just implements
>>> the raw api and nothing else and does not take some corner conditions
>>> into consideration and has no browser optimizations they are
>>> significantly smaller in their jsf.js file and if our size is a problem
>>> we can reduce it.
>>>
>>>
>>>
>>>
>>> Werner
>>>
>>>
>>> Am 10/13/11 11:07 PM, schrieb Leonardo Uribe:
>>>> Hi
>>>>
>>>> I believe probably we already did that. The biggest bottleneck we had
>>>> was that renderers did many calls to map.get(). Mojarra had an
>>>> optimization in this part, but MyFaces do not until 2.0.9/2.1.3, so I
>>>> suppose with the latest code we have better numbers.
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>> 2011/10/13 Werner Punz<we...@gmail.com>:
>>>>> I would be interested as well, especially regarding their test setup,
>>> we
>>>>> basically doubled for instance our ajax performance between 2.0.4 and
>>> the
>>>>> current state of affairs.
>>>>>
>>>>> So it might be interesting to see what testsetup they were using.
>>>>> From a pure memory point of view we of course have a higher load on
>>> the
>>>>> browser because our ajax implementation deals with things mojarra does
>>> not
>>>>> and also has an oo layer underneath. But I added browser specific
>>>>> optimisations so on modern browsers we should be slightly faster than
>>>>> mojarra in raw ajax processing (at least my personal tests resembled
>>> that
>>>>> when I did the profiling), while mojarra is sligtly ahead on Firefox
>>> 3.5 and
>>>>> IE6 and 7.
>>>>>
>>>>> Just giving the numbers unfortunately does not help to see where their
>>>>> bottleneck was they discovered.
>>>>>
>>>>>
>>>>>
>>>>> Werner
>>>>>
>>>>>
>>>>> Am 10/13/11 10:13 PM, schrieb Andy Schwartz:
>>>>>>
>>>>>> Gang -
>>>>>>
>>>>>> I recently got wind of the following web framework performance talk
>>>>>> that was presented at JavaOne:
>>>>>>
>>>>>>
>>>>>>
>>> https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf
>>>
>>>>>>
>>>>>> I did not attend, but based on the slides it looks like the
>>> presenters
>>>>>> did an very thorough/systematic job of evaluating
>>>>>> performance/scalability for a handful of web frameworks, including
>>>>>> JSF. (I also have to say that they slides are simply beautiful -
>>>>>> wow!)
>>>>>>
>>>>>> I wanted to call attention to this talk because I am concerned
>>> about
>>>>>> one aspect of the results. Looking at slide #73, it seems that the
>>>>>> presenters are seeing significant overhead in the MyFaces test runs
>>>>>> (ie. vs. equivalent runs in Mojarra). I don't have any details
>>> other
>>>>>> than the $ numbers included in the slides, but seems quite possible
>>>>>> that there is some low-hanging fruit waiting to be picked (or
>>>>>> optimized).
>>>>>>
>>>>>> Is anyone acquainted with the presenters? Perhaps it would be
>>>>>> worthwhile to contact them to see whether it would be possible to
>>> take
>>>>>> a closer look at the test case?
>>>>>>
>>>>>> Andy
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
Re: Web Framework Performance Comparision
Posted by Werner Punz <we...@gmail.com>.
Hi, I got an answer from one of the guys over twitter.
They were using MyFaces 2.1.1, I am trying to find out if they used
Development stage or Production. I also gave him the hint to try
Myfaces 2.1.4-Snapshot.
It might be interesting to see their tests revisited with 2.1.4.
Werner
Am 10/14/11 11:40 AM, schrieb Mark Struberg:
> I got to similar numbers WHEN I was in ProjectStaged.Development only. In this case we have our DebugPhaseListener running and lots of other stuff as well.
>
> Once I benched with PS.Production, the numbers were pretty well.
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Werner Punz<we...@gmail.com>
>> To: dev@myfaces.apache.org
>> Cc:
>> Sent: Thursday, October 13, 2011 11:20 PM
>> Subject: Re: Web Framework Performance Comparision
>>
>> Yes from what i gather one of the issues they had in the slides was the
>> overall page size. The question there is more along the lines what did
>> they count, just the rendered code, or also the includes.
>>
>> I can help to reduce the size on the JSF.js side. We have some code
>> which is not directly active for JSF 2.1 and will very likely become
>> part of jsf 2.2 or 2.3. it can be used today already by adding config
>> params, Also we have some internationalization
>> of the internal error messages.
>>
>> This code could be externalized into an addition js file for people who
>> need it. I think we might save around 20Kbytes that way.
>>
>> I personally did not think that it was necessary due to the fact that
>> the js files usually are gzipped while still bigger than mojarra we
>> after gzipping the file talk about sizes of 10-30k etc...
>>
>> In the end externalizing that code would have caused more burden on the
>> users than it would have helped. But given that mojarra just implements
>> the raw api and nothing else and does not take some corner conditions
>> into consideration and has no browser optimizations they are
>> significantly smaller in their jsf.js file and if our size is a problem
>> we can reduce it.
>>
>>
>>
>>
>> Werner
>>
>>
>> Am 10/13/11 11:07 PM, schrieb Leonardo Uribe:
>>> Hi
>>>
>>> I believe probably we already did that. The biggest bottleneck we had
>>> was that renderers did many calls to map.get(). Mojarra had an
>>> optimization in this part, but MyFaces do not until 2.0.9/2.1.3, so I
>>> suppose with the latest code we have better numbers.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2011/10/13 Werner Punz<we...@gmail.com>:
>>>> I would be interested as well, especially regarding their test setup,
>> we
>>>> basically doubled for instance our ajax performance between 2.0.4 and
>> the
>>>> current state of affairs.
>>>>
>>>> So it might be interesting to see what testsetup they were using.
>>>> From a pure memory point of view we of course have a higher load on
>> the
>>>> browser because our ajax implementation deals with things mojarra does
>> not
>>>> and also has an oo layer underneath. But I added browser specific
>>>> optimisations so on modern browsers we should be slightly faster than
>>>> mojarra in raw ajax processing (at least my personal tests resembled
>> that
>>>> when I did the profiling), while mojarra is sligtly ahead on Firefox
>> 3.5 and
>>>> IE6 and 7.
>>>>
>>>> Just giving the numbers unfortunately does not help to see where their
>>>> bottleneck was they discovered.
>>>>
>>>>
>>>>
>>>> Werner
>>>>
>>>>
>>>> Am 10/13/11 10:13 PM, schrieb Andy Schwartz:
>>>>>
>>>>> Gang -
>>>>>
>>>>> I recently got wind of the following web framework performance talk
>>>>> that was presented at JavaOne:
>>>>>
>>>>>
>>>>>
>> https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf
>>>>>
>>>>> I did not attend, but based on the slides it looks like the
>> presenters
>>>>> did an very thorough/systematic job of evaluating
>>>>> performance/scalability for a handful of web frameworks, including
>>>>> JSF. (I also have to say that they slides are simply beautiful -
>>>>> wow!)
>>>>>
>>>>> I wanted to call attention to this talk because I am concerned
>> about
>>>>> one aspect of the results. Looking at slide #73, it seems that the
>>>>> presenters are seeing significant overhead in the MyFaces test runs
>>>>> (ie. vs. equivalent runs in Mojarra). I don't have any details
>> other
>>>>> than the $ numbers included in the slides, but seems quite possible
>>>>> that there is some low-hanging fruit waiting to be picked (or
>>>>> optimized).
>>>>>
>>>>> Is anyone acquainted with the presenters? Perhaps it would be
>>>>> worthwhile to contact them to see whether it would be possible to
>> take
>>>>> a closer look at the test case?
>>>>>
>>>>> Andy
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>
Re: Web Framework Performance Comparision
Posted by Werner Punz <we...@gmail.com>.
Yes, that was the reason why I went in my comparison with production as
well. Because development simply is a development mode where performance
is a non issue.
I also have some performance burners in my js files as well when run in
development mode.
The entire test looks rather fishy to me given that they do not reveal
their test setup and their test numbers.
Their test methods and how they cam to the TOC conclusions is also not
entirely revealed only partially.
Werner
Am 10/14/11 11:40 AM, schrieb Mark Struberg:
> I got to similar numbers WHEN I was in ProjectStaged.Development only. In this case we have our DebugPhaseListener running and lots of other stuff as well.
>
> Once I benched with PS.Production, the numbers were pretty well.
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
>> From: Werner Punz<we...@gmail.com>
>> To: dev@myfaces.apache.org
>> Cc:
>> Sent: Thursday, October 13, 2011 11:20 PM
>> Subject: Re: Web Framework Performance Comparision
>>
>> Yes from what i gather one of the issues they had in the slides was the
>> overall page size. The question there is more along the lines what did
>> they count, just the rendered code, or also the includes.
>>
>> I can help to reduce the size on the JSF.js side. We have some code
>> which is not directly active for JSF 2.1 and will very likely become
>> part of jsf 2.2 or 2.3. it can be used today already by adding config
>> params, Also we have some internationalization
>> of the internal error messages.
>>
>> This code could be externalized into an addition js file for people who
>> need it. I think we might save around 20Kbytes that way.
>>
>> I personally did not think that it was necessary due to the fact that
>> the js files usually are gzipped while still bigger than mojarra we
>> after gzipping the file talk about sizes of 10-30k etc...
>>
>> In the end externalizing that code would have caused more burden on the
>> users than it would have helped. But given that mojarra just implements
>> the raw api and nothing else and does not take some corner conditions
>> into consideration and has no browser optimizations they are
>> significantly smaller in their jsf.js file and if our size is a problem
>> we can reduce it.
>>
>>
>>
>>
>> Werner
>>
>>
>> Am 10/13/11 11:07 PM, schrieb Leonardo Uribe:
>>> Hi
>>>
>>> I believe probably we already did that. The biggest bottleneck we had
>>> was that renderers did many calls to map.get(). Mojarra had an
>>> optimization in this part, but MyFaces do not until 2.0.9/2.1.3, so I
>>> suppose with the latest code we have better numbers.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2011/10/13 Werner Punz<we...@gmail.com>:
>>>> I would be interested as well, especially regarding their test setup,
>> we
>>>> basically doubled for instance our ajax performance between 2.0.4 and
>> the
>>>> current state of affairs.
>>>>
>>>> So it might be interesting to see what testsetup they were using.
>>>> From a pure memory point of view we of course have a higher load on
>> the
>>>> browser because our ajax implementation deals with things mojarra does
>> not
>>>> and also has an oo layer underneath. But I added browser specific
>>>> optimisations so on modern browsers we should be slightly faster than
>>>> mojarra in raw ajax processing (at least my personal tests resembled
>> that
>>>> when I did the profiling), while mojarra is sligtly ahead on Firefox
>> 3.5 and
>>>> IE6 and 7.
>>>>
>>>> Just giving the numbers unfortunately does not help to see where their
>>>> bottleneck was they discovered.
>>>>
>>>>
>>>>
>>>> Werner
>>>>
>>>>
>>>> Am 10/13/11 10:13 PM, schrieb Andy Schwartz:
>>>>>
>>>>> Gang -
>>>>>
>>>>> I recently got wind of the following web framework performance talk
>>>>> that was presented at JavaOne:
>>>>>
>>>>>
>>>>>
>> https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf
>>>>>
>>>>> I did not attend, but based on the slides it looks like the
>> presenters
>>>>> did an very thorough/systematic job of evaluating
>>>>> performance/scalability for a handful of web frameworks, including
>>>>> JSF. (I also have to say that they slides are simply beautiful -
>>>>> wow!)
>>>>>
>>>>> I wanted to call attention to this talk because I am concerned
>> about
>>>>> one aspect of the results. Looking at slide #73, it seems that the
>>>>> presenters are seeing significant overhead in the MyFaces test runs
>>>>> (ie. vs. equivalent runs in Mojarra). I don't have any details
>> other
>>>>> than the $ numbers included in the slides, but seems quite possible
>>>>> that there is some low-hanging fruit waiting to be picked (or
>>>>> optimized).
>>>>>
>>>>> Is anyone acquainted with the presenters? Perhaps it would be
>>>>> worthwhile to contact them to see whether it would be possible to
>> take
>>>>> a closer look at the test case?
>>>>>
>>>>> Andy
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>
Re: Web Framework Performance Comparision
Posted by Mark Struberg <st...@yahoo.de>.
I got to similar numbers WHEN I was in ProjectStaged.Development only. In this case we have our DebugPhaseListener running and lots of other stuff as well.
Once I benched with PS.Production, the numbers were pretty well.
LieGrue,
strub
----- Original Message -----
> From: Werner Punz <we...@gmail.com>
> To: dev@myfaces.apache.org
> Cc:
> Sent: Thursday, October 13, 2011 11:20 PM
> Subject: Re: Web Framework Performance Comparision
>
> Yes from what i gather one of the issues they had in the slides was the
> overall page size. The question there is more along the lines what did
> they count, just the rendered code, or also the includes.
>
> I can help to reduce the size on the JSF.js side. We have some code
> which is not directly active for JSF 2.1 and will very likely become
> part of jsf 2.2 or 2.3. it can be used today already by adding config
> params, Also we have some internationalization
> of the internal error messages.
>
> This code could be externalized into an addition js file for people who
> need it. I think we might save around 20Kbytes that way.
>
> I personally did not think that it was necessary due to the fact that
> the js files usually are gzipped while still bigger than mojarra we
> after gzipping the file talk about sizes of 10-30k etc...
>
> In the end externalizing that code would have caused more burden on the
> users than it would have helped. But given that mojarra just implements
> the raw api and nothing else and does not take some corner conditions
> into consideration and has no browser optimizations they are
> significantly smaller in their jsf.js file and if our size is a problem
> we can reduce it.
>
>
>
>
> Werner
>
>
> Am 10/13/11 11:07 PM, schrieb Leonardo Uribe:
>> Hi
>>
>> I believe probably we already did that. The biggest bottleneck we had
>> was that renderers did many calls to map.get(). Mojarra had an
>> optimization in this part, but MyFaces do not until 2.0.9/2.1.3, so I
>> suppose with the latest code we have better numbers.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>> 2011/10/13 Werner Punz<we...@gmail.com>:
>>> I would be interested as well, especially regarding their test setup,
> we
>>> basically doubled for instance our ajax performance between 2.0.4 and
> the
>>> current state of affairs.
>>>
>>> So it might be interesting to see what testsetup they were using.
>>> From a pure memory point of view we of course have a higher load on
> the
>>> browser because our ajax implementation deals with things mojarra does
> not
>>> and also has an oo layer underneath. But I added browser specific
>>> optimisations so on modern browsers we should be slightly faster than
>>> mojarra in raw ajax processing (at least my personal tests resembled
> that
>>> when I did the profiling), while mojarra is sligtly ahead on Firefox
> 3.5 and
>>> IE6 and 7.
>>>
>>> Just giving the numbers unfortunately does not help to see where their
>>> bottleneck was they discovered.
>>>
>>>
>>>
>>> Werner
>>>
>>>
>>> Am 10/13/11 10:13 PM, schrieb Andy Schwartz:
>>>>
>>>> Gang -
>>>>
>>>> I recently got wind of the following web framework performance talk
>>>> that was presented at JavaOne:
>>>>
>>>>
>>>>
> https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf
>>>>
>>>> I did not attend, but based on the slides it looks like the
> presenters
>>>> did an very thorough/systematic job of evaluating
>>>> performance/scalability for a handful of web frameworks, including
>>>> JSF. (I also have to say that they slides are simply beautiful -
>>>> wow!)
>>>>
>>>> I wanted to call attention to this talk because I am concerned
> about
>>>> one aspect of the results. Looking at slide #73, it seems that the
>>>> presenters are seeing significant overhead in the MyFaces test runs
>>>> (ie. vs. equivalent runs in Mojarra). I don't have any details
> other
>>>> than the $ numbers included in the slides, but seems quite possible
>>>> that there is some low-hanging fruit waiting to be picked (or
>>>> optimized).
>>>>
>>>> Is anyone acquainted with the presenters? Perhaps it would be
>>>> worthwhile to contact them to see whether it would be possible to
> take
>>>> a closer look at the test case?
>>>>
>>>> Andy
>>>>
>>>
>>>
>>>
>>
>
Re: Web Framework Performance Comparision
Posted by Werner Punz <we...@gmail.com>.
Yes from what i gather one of the issues they had in the slides was the
overall page size. The question there is more along the lines what did
they count, just the rendered code, or also the includes.
I can help to reduce the size on the JSF.js side. We have some code
which is not directly active for JSF 2.1 and will very likely become
part of jsf 2.2 or 2.3. it can be used today already by adding config
params, Also we have some internationalization
of the internal error messages.
This code could be externalized into an addition js file for people who
need it. I think we might save around 20Kbytes that way.
I personally did not think that it was necessary due to the fact that
the js files usually are gzipped while still bigger than mojarra we
after gzipping the file talk about sizes of 10-30k etc...
In the end externalizing that code would have caused more burden on the
users than it would have helped. But given that mojarra just implements
the raw api and nothing else and does not take some corner conditions
into consideration and has no browser optimizations they are
significantly smaller in their jsf.js file and if our size is a problem
we can reduce it.
Werner
Am 10/13/11 11:07 PM, schrieb Leonardo Uribe:
> Hi
>
> I believe probably we already did that. The biggest bottleneck we had
> was that renderers did many calls to map.get(). Mojarra had an
> optimization in this part, but MyFaces do not until 2.0.9/2.1.3, so I
> suppose with the latest code we have better numbers.
>
> regards,
>
> Leonardo Uribe
>
> 2011/10/13 Werner Punz<we...@gmail.com>:
>> I would be interested as well, especially regarding their test setup, we
>> basically doubled for instance our ajax performance between 2.0.4 and the
>> current state of affairs.
>>
>> So it might be interesting to see what testsetup they were using.
>> From a pure memory point of view we of course have a higher load on the
>> browser because our ajax implementation deals with things mojarra does not
>> and also has an oo layer underneath. But I added browser specific
>> optimisations so on modern browsers we should be slightly faster than
>> mojarra in raw ajax processing (at least my personal tests resembled that
>> when I did the profiling), while mojarra is sligtly ahead on Firefox 3.5 and
>> IE6 and 7.
>>
>> Just giving the numbers unfortunately does not help to see where their
>> bottleneck was they discovered.
>>
>>
>>
>> Werner
>>
>>
>> Am 10/13/11 10:13 PM, schrieb Andy Schwartz:
>>>
>>> Gang -
>>>
>>> I recently got wind of the following web framework performance talk
>>> that was presented at JavaOne:
>>>
>>>
>>> https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf
>>>
>>> I did not attend, but based on the slides it looks like the presenters
>>> did an very thorough/systematic job of evaluating
>>> performance/scalability for a handful of web frameworks, including
>>> JSF. (I also have to say that they slides are simply beautiful -
>>> wow!)
>>>
>>> I wanted to call attention to this talk because I am concerned about
>>> one aspect of the results. Looking at slide #73, it seems that the
>>> presenters are seeing significant overhead in the MyFaces test runs
>>> (ie. vs. equivalent runs in Mojarra). I don't have any details other
>>> than the $ numbers included in the slides, but seems quite possible
>>> that there is some low-hanging fruit waiting to be picked (or
>>> optimized).
>>>
>>> Is anyone acquainted with the presenters? Perhaps it would be
>>> worthwhile to contact them to see whether it would be possible to take
>>> a closer look at the test case?
>>>
>>> Andy
>>>
>>
>>
>>
>
Re: Web Framework Performance Comparision
Posted by Leonardo Uribe <lu...@gmail.com>.
Hi
I believe probably we already did that. The biggest bottleneck we had
was that renderers did many calls to map.get(). Mojarra had an
optimization in this part, but MyFaces do not until 2.0.9/2.1.3, so I
suppose with the latest code we have better numbers.
regards,
Leonardo Uribe
2011/10/13 Werner Punz <we...@gmail.com>:
> I would be interested as well, especially regarding their test setup, we
> basically doubled for instance our ajax performance between 2.0.4 and the
> current state of affairs.
>
> So it might be interesting to see what testsetup they were using.
> From a pure memory point of view we of course have a higher load on the
> browser because our ajax implementation deals with things mojarra does not
> and also has an oo layer underneath. But I added browser specific
> optimisations so on modern browsers we should be slightly faster than
> mojarra in raw ajax processing (at least my personal tests resembled that
> when I did the profiling), while mojarra is sligtly ahead on Firefox 3.5 and
> IE6 and 7.
>
> Just giving the numbers unfortunately does not help to see where their
> bottleneck was they discovered.
>
>
>
> Werner
>
>
> Am 10/13/11 10:13 PM, schrieb Andy Schwartz:
>>
>> Gang -
>>
>> I recently got wind of the following web framework performance talk
>> that was presented at JavaOne:
>>
>>
>> https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf
>>
>> I did not attend, but based on the slides it looks like the presenters
>> did an very thorough/systematic job of evaluating
>> performance/scalability for a handful of web frameworks, including
>> JSF. (I also have to say that they slides are simply beautiful -
>> wow!)
>>
>> I wanted to call attention to this talk because I am concerned about
>> one aspect of the results. Looking at slide #73, it seems that the
>> presenters are seeing significant overhead in the MyFaces test runs
>> (ie. vs. equivalent runs in Mojarra). I don't have any details other
>> than the $ numbers included in the slides, but seems quite possible
>> that there is some low-hanging fruit waiting to be picked (or
>> optimized).
>>
>> Is anyone acquainted with the presenters? Perhaps it would be
>> worthwhile to contact them to see whether it would be possible to take
>> a closer look at the test case?
>>
>> Andy
>>
>
>
>
Re: Web Framework Performance Comparision
Posted by Werner Punz <we...@gmail.com>.
I would be interested as well, especially regarding their test setup, we
basically doubled for instance our ajax performance between 2.0.4 and
the current state of affairs.
So it might be interesting to see what testsetup they were using.
From a pure memory point of view we of course have a higher load on the
browser because our ajax implementation deals with things mojarra does
not and also has an oo layer underneath. But I added browser specific
optimisations so on modern browsers we should be slightly faster than
mojarra in raw ajax processing (at least my personal tests resembled
that when I did the profiling), while mojarra is sligtly ahead on
Firefox 3.5 and IE6 and 7.
Just giving the numbers unfortunately does not help to see where their
bottleneck was they discovered.
Werner
Am 10/13/11 10:13 PM, schrieb Andy Schwartz:
> Gang -
>
> I recently got wind of the following web framework performance talk
> that was presented at JavaOne:
>
> https://oracleus.wingateweb.com/published/oracleus2011/sessions/24122/S24122_234496.pdf
>
> I did not attend, but based on the slides it looks like the presenters
> did an very thorough/systematic job of evaluating
> performance/scalability for a handful of web frameworks, including
> JSF. (I also have to say that they slides are simply beautiful -
> wow!)
>
> I wanted to call attention to this talk because I am concerned about
> one aspect of the results. Looking at slide #73, it seems that the
> presenters are seeing significant overhead in the MyFaces test runs
> (ie. vs. equivalent runs in Mojarra). I don't have any details other
> than the $ numbers included in the slides, but seems quite possible
> that there is some low-hanging fruit waiting to be picked (or
> optimized).
>
> Is anyone acquainted with the presenters? Perhaps it would be
> worthwhile to contact them to see whether it would be possible to take
> a closer look at the test case?
>
> Andy
>