Ryan Lubke has posted "JSF RI Performance/Scalability," in which he shows some metrics gathered from the latest JSF reference implementation release, showing a noticable increase in performance in both the client-side state save mode and the server-side state save mode. For the single-CPU test, the latest version gained 17 operations per second, from 53 to 70, on the server-side state mode (in which the server attaches the component model to a session and retains it internally.) Using the mode where the component model is serialized in the JSF-generated content, the operations/second went from 27 to 43, a gain of 16 operations per second. It's excellent news to see something like this, because it's a recognition that JSF's performance might not be there yet, and it's also a demonstration that improvements are being searched for and applied.

70 - 53 = 17

70 - 53 = 17

Errrrrmmm... duh. Okay, I'm going to fix the news post (it had "For the single-CPU test, the latest version gained 13 operations per second, from 53 to 70...") and I'm ALSO going to pretend I was on heavy medication and, um, look! A bird!

um, look! A bird!

I use that. .V

It's excellent news to see something like this, because it's a recognition that JSF's performance might not be there yet, and it's also a demonstration that improvements are being searched for and applied.

And it is good to see actual numbers that show that client state saving comes with a cost as well; server state saving can work fine depending on your usage characteristics. It would be interesting to see the load on the network as well .

It's excellent news to see something like this, because it's a recognition that JSF's performance might not be there yet, and it's also a demonstration that improvements are being searched for and applied.

And it is good to see actual numbers that show that client state saving comes with a cost as well; server state saving can work fine depending on your usage characteristics.

It would be interesting to see the load on the network as well .

http://weblogs.java.net/blog/jhook/archive/2006/12/jsf_statesaving_1.html

It's excellent news to see something like this, because it's a recognition that JSF's performance might not be there yet, and it's also a demonstration that improvements are being searched for and applied.

And it is good to see actual numbers that show that client state saving comes with a cost as well; server state saving can work fine depending on your usage characteristics.

It would be interesting to see the load on the network as well .

Actually the impact on client side state saving is not neglectable, you basically stream a lot more data into the client. It used to be the only method to achieve a good back button behavior, but the RI and myfaces have fixed this problem to a good extent by recovering old states in back button situations, even on server side state saving. The main issue is to keep the savestated data as small as possible, I think jsf 1.2 has targeted this problem by allowing the handling of subtrees. (Not that the data really is that much anyway, most jsf implementations have tried to avoid simple serialisation in favor of direct data to array conversion for exactly this reason)

Please, take a look at the metrics proposed here http://forum.java.sun.com/thread.jspa?threadID=5209771 They would also allow to benchmark JSF performance against JSP. RENDER phase measured against number of components of the page and against number or data rows (to identify scalability) APPLY REQUEST VALUES measured against number of components of the page and against number or data rows with input controls submitted with a form (to identify scalability) Same results are compared with JSP. Backing bean is simple get/set so performance metrics are accurate indication of JSF performance (not tied up with other technologies used on backend) Regards