Questions about JSFCentral - Understanding JSF 2.0 Performance - Part 3

["Howard W. Smith, Jr." <sm...@gmail.com>]

First of all, kudos for the following blog/post:

JSFCentral - Understanding JSF 2.0 Performance - Part 3[1]

I started reading this, and not done yet.

>> Instead, it's more interesting to check the ability of a web framework
to deal with effects like concurrency and get an idea of the overhead
involved in using a web framework against the fastest possible solution in
Java.

So far, I'm seeing, possibly, latest releases of open source software used
in the test...except for the JDK. Does 'fastest possible solution in Java'
= JDK6.0.30?

JDK7 has been available for quite some time and I know I'm using JDK7
(latest version, always), and JDK8 is out there and around the corner.

Is there any reason why Java = JDK6.0.30 in the tests?


[1] http://www.jsfcentral.com/articles/understanding_jsf_performance_3.html

Re: Questions about JSFCentral - Understanding JSF 2.0 Performance - Part 3

["Howard W. Smith, Jr." <sm...@gmail.com>]

Okay/understood, thanks Leonardo. :)

>> The most interesting fact is the decrease in the throughput for Spring
MVC.

I found that interesting too.

>> If you think that using Spring MVC-JSP will give you a better
performance, think twice, because MyFaces with a CDI implementation like
OpenWebbeans will do a better job.

And I was glad to see this mentioned... I'm definitely using all of the
above (MyFaces Core + OpenWebBeans + CDI via TomEE 1.6.0 snapshot). :)

I think I have been using MyFaces Core ever since August or September 2012,
and I have been very satisfied with the performance, and GC does not seem
to be an issue in/with my app as my app has been running perfectly at -Xms1250m
-Xmx1250m -server. Honestly, I don't ever remember experiencing an
OutOfMemory issue with my app. :)

>> Servlet-JSP uses the least possible amount of memory, but the surprising
part is MyFaces uses 32% less memory than Spring MVC-JSP, and in the best
case the view pool uses 46% less memory.  That means in some cases under
high load and low memory, MyFaces will probably perform better than Spring
MVC-JSP due to the garbage collector effect.

Very interesting. Prior to reading this blog of yours, I was not aware of
how well Servlet-JSP performs compared to JSF, and now I'm glad to see
Spring MVC JSP included in the comparisons as well.

I will be honest with you, when I look at Instances in jvisualvm, I see
more MyFaces Core instances than instances of my classes, and the MyFaces
Core instances seem to take up more memory than instances of my classes.

>>  This feature is ideal for viewing the session size—just look for
org.apache.catalina.session.StandardSession retained size

While reading, I was just about to ask about this, and now I know. Since
I'm not using Yourkit, I hope I can see the session size in jvisualvm (or
Netbeans profiler).

Anyway, very nice-n-informative blog/post/article. Thank you!



On Wed, Jul 17, 2013 at 10:13 AM, Leonardo Uribe <lu...@gmail.com> wrote:

> Hi Howard
>
> JSF 2.1 is java 1.6 compatible. In this case, an improvement in the JVM
> will affect all frameworks in the same way, so a change using java 7 or 8
> will not affect the relative differences.
>
> Regards,
>
> Leonardo.
> On Jul 17, 2013 1:32 PM, "Howard W. Smith, Jr." <sm...@gmail.com>
> wrote:
>
> > First of all, kudos for the following blog/post:
> >
> > JSFCentral - Understanding JSF 2.0 Performance - Part 3[1]
> >
> > I started reading this, and not done yet.
> >
> > >> Instead, it's more interesting to check the ability of a web framework
> > to deal with effects like concurrency and get an idea of the overhead
> > involved in using a web framework against the fastest possible solution
> in
> > Java.
> >
> > So far, I'm seeing, possibly, latest releases of open source software
> used
> > in the test...except for the JDK. Does 'fastest possible solution in
> Java'
> > = JDK6.0.30?
> >
> > JDK7 has been available for quite some time and I know I'm using JDK7
> > (latest version, always), and JDK8 is out there and around the corner.
> >
> > Is there any reason why Java = JDK6.0.30 in the tests?
> >
> >
> > [1]
> > http://www.jsfcentral.com/articles/understanding_jsf_performance_3.html
> >
>

Re: Questions about JSFCentral - Understanding JSF 2.0 Performance - Part 3

[Leonardo Uribe <lu...@gmail.com>]

Hi Howard

JSF 2.1 is java 1.6 compatible. In this case, an improvement in the JVM
will affect all frameworks in the same way, so a change using java 7 or 8
will not affect the relative differences.

Regards,

Leonardo.
On Jul 17, 2013 1:32 PM, "Howard W. Smith, Jr." <sm...@gmail.com>
wrote:

> First of all, kudos for the following blog/post:
>
> JSFCentral - Understanding JSF 2.0 Performance - Part 3[1]
>
> I started reading this, and not done yet.
>
> >> Instead, it's more interesting to check the ability of a web framework
> to deal with effects like concurrency and get an idea of the overhead
> involved in using a web framework against the fastest possible solution in
> Java.
>
> So far, I'm seeing, possibly, latest releases of open source software used
> in the test...except for the JDK. Does 'fastest possible solution in Java'
> = JDK6.0.30?
>
> JDK7 has been available for quite some time and I know I'm using JDK7
> (latest version, always), and JDK8 is out there and around the corner.
>
> Is there any reason why Java = JDK6.0.30 in the tests?
>
>
> [1]
> http://www.jsfcentral.com/articles/understanding_jsf_performance_3.html
>