Win a copy of Cross-Platform Desktop Applications: Using Node, Electron, and NW.js this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Any ways to optimize complex JSF/Primefaces views "response speed"?  RSS feed

 
Akaine Harga
Ranch Hand
Posts: 99
Java MyEclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've been working with JSF1/2 and Primefaces for a few years by now and many times I ended up with clients complaining about page response times. My answer in most of these cases is: "What do you want? You've asked me to put half of the whole application's functionality on one page. Of course it will be slow." Yes, I'm talking about those pages where the client wants too see and control just everything, when even if а mosquito that flies by suddenly farts, the page should show it. So, on a functional level I see no problem: we put a dozen of containers here, dozen of buttons there, some more output containers over there, and everything is freakin' dynamic, of course. I certainly try to minimize the messages that are being sent or received to/from the server limiting them almost to numbers and Strings, but this is not enough.

The main problem, as far as I see it, is the partial DOM update, where I have to rerender certain parts of a page (and sometimes almost the whole page) to update the data. And, holy ***, this does take time. And the more complex your view structure is - the more time these DOM updates take. So in the end depending on the page's structure it could take 20 or even 40 seconds to see the update, especially on mobile devices. I understand this is a jQuery/JavaScript related problem, but I don't believe I'm the first one to raise this topic.

Are there any methods to optimize or reduce a complex JSF/Primefaces view response time without sacrificing all the epicness of web2 concept?

To clarify the case I am talking about let's see a real-life example.

I have a quote creation page for a house repairs company (page image).
This page allows user to create unlimited stages of repairs. Each stage can have an unlimited number of sections or areas. Each section/area can contain an unlimited number of repair jobs. Each time a job is added/modified the area subtotals and grand totals are being updated (job cost, materials cost, completion time, etc.). So in this particular case while a small number jobs is handled (10-30) all is fine. But when we pass to hundreds each new operation begins to take more and more time, until the response time is just "not acceptable".

I've already spent some time trying to optimize it, but I it seems I cannot solve this problem alone.

Any suggestions?
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Generally, JSF (these days) is best when you are taking advantage of the automatic property binding to backing beans as you would in CRUD pages. You're better off using stateless views for dashboard type pages with data fetched via AJAX rather than trying to fit that into JSF's bindings.
You can still use JSF for the page (to take advantage of templating or for uniformity with other pages) but rather use restful services for getting the data from the server and use JQuery to fetch the data and set it on the page controls.
That will make your page load quickly while delaying only the data fetching part. You also have control of when you want to fetch the data and which data you want refreshed because you are explicitly making the data calls to the sever from the client side.
Any performance issues that arise with this structure will thus not be related to the framework.
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would second Mr. Armitage's suggestion. If the page is primarily display information, one of the virtues of JSF is that you can switch to a more effective strategy for high-stress views.

On the other hand, here are some considerations for optimizing JSF itself.

First, employ a performance tool to see what your network traffic choke points are. I use the FireFly plugin with Firefox for example. This pointed out to me 2 things: First, that over 300K of javascript was being downloaded on each View and secondly, that the same 300K was being downloaded on EACH View.

The server in question was Tomcat. For security reasons, Tomcat overrides caching when SSL is in effect. So what I did was write a servlet filter that would disable that override for JavaScript and image files. So there was still an initial hit the first time the JSF support JavaScript code was pulled, but once it was downloaded, it was served from the client's local cache for the remainder of the session.

The other thing to pay close attention to is how much of the page is being updated. You want to keep this set as small as possible, allowing for the limitations of the framework. For example, JSF doesn't permit updating a single row in a table subview, because JSF doesn't have the ability to address rows individually. But if you have 5 areas on the page that need updating, you're likely to get better performance if you specify that AJAX should re-render just those 5 areas and not simply pick a page sub-element that encloses all 5 of them plus stuff that doesn't require updating. Once again, FireFly helps me here because I can see the exact text of the update response. which will help be see if unrelated items are being force-updated when they don't need to be.

One thing that MIGHT also help would be to employ multiple forms in the View, if this is possible. Since the extent of a request/response is limited to the form being submitted, that can limit the amount of data being transferred by its very nature.
 
Akaine Harga
Ranch Hand
Posts: 99
Java MyEclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, guys. A lot of interesting comments here.

I always limit all my requests using ajax partialSubmit and listing specific ids to submit, so no whole form requests here. Same with updates: I rarely update an entire container. But, as Tim Holloway mentioned, sometimes it's impossible to update only one subtable's row using just PF.

E Armitage wrote:Generally, JSF (these days) is best when you are taking advantage of the automatic property binding to backing beans as you would in CRUD pages. You're better off using stateless views for dashboard type pages with data fetched via AJAX rather than trying to fit that into JSF's bindings. You can still use JSF for the page (to take advantage of templating or for uniformity with other pages) but rather use restful services for getting the data from the server and use JQuery to fetch the data and set it on the page controls.

You mean I should forget about property binding and manually use jQuery for data fetching and view updates? And that without mentioning the stateless views. But wouldn't that multiply the required time for coding, code complexity in several times and render the best JSF's feature (variable binding) just useless? I'm not entirely against the idea, I just need time to get used to it, I guess.

Actually, guys, one of the purposes of my post was exactly this:
Is JSF (or any other "automated" WebMVC) good for heavy views? Or am I actually hitting the limits here? I was considering to move to JavaFX8 for some time by now. As far as I understand I won't have any of these problem there. Or even forget Java completely and move to .Net SOA based apps. Because the idea of spending weeks of jQuery coding for a relatively simple functionality doesn't appeal to me as the most optimal (time/cost) solution.

Any thoughts?
 
Tim Holloway
Bartender
Posts: 18662
71
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, a number of the JSF extension frameworks have used jQuery "under the hood" to implement their AJAX functionality. And they generally have also been pretty co-operative in allowing JSF to use jQuery directly.

I don't know that raw jQuery can give you a whole lot. If you want to send or receive just one row of a table, the Model/View breakdown is basically Level 1: all of table, Level 2, individual elements in table. To optimally handle a selected set of rows you need to either locate a smarter dataTable control where there's a sub-View for each row or invent your own. If you try for brute-force jQuery, then you'd need to submit/render external to JSF, since the JSF lifecycle would otherwise object to missing pieces.

Of course, you could hack it by stacking multiple 1-row tables to look like a multi-row table. I've pulled stunts like that on pre-JSF HTML apps. Eek.

I've never gotten a good feel for JSF's ability to handle load conditions. JSF carries a lot of freight, but I don't have solid numbers on whether it actually is that expensive overall. But my concern is more with what happens when you have 350 people all working the same app at the same time. If you cannot avoid putting the entire universe on-screen at once, I'm not sure that the difference in performance on JSF versus raw HTML/AJAX is going to be that much of a difference. Two tons of fertilizer in a one-ton truck is still two tons of fertilizer in a one-ton truck.

Speaking of unrealistic expectations, did I ever mention the project they gave me back in my mainframe days? It consisted of a 7-level report done multiple ways. We estimated that each daily run was going to consume 2 and a half 2500-sheet boxes of fanfold paper and propably no more than a page or 2 of the report would ever be actually looked at at any given time.

Fortunately, we managed to persuade the users in the direction of sanity.
 
Akaine Harga
Ranch Hand
Posts: 99
Java MyEclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, as I mentioned in my first post the question was about Primefaces based views. So I do have loads of jQuery, just not written manually. This is the problem: I already limit my requests to 1-10 parameters and update only the parts I need to update (as far as PF allows me to), and it's still slow. That's why I started to talk about "Should I forget about JSF as a "quick-to-build" web app dev tool? The apps look nice, they require little coding, but they are slow. And with the Internet connection becoming faster each year people will start complaining more and more.

Tim Holloway wrote:Of course, you could hack it by stacking multiple 1-row tables to look like a multi-row table. I've pulled stunts like that on pre-JSF HTML apps. Eek.

That's exactly the perverse stuff what I was doing to my heavy views. But this is called "putting crutches so the skyscraper wouldn't fall". We are hitting the WebMVC's limits here, aren't we...

Tim Holloway wrote:Speaking of unrealistic expectations, did I ever mention the project they gave me back in my mainframe days? It consisted of a 7-level report done multiple ways. We estimated that each daily run was going to consume 2 and a half 2500-sheet boxes of fanfold paper and propably no more than a page or 2 of the report would ever be actually looked at at any given time. Fortunately, we managed to persuade the users in the direction of sanity.
XDDD In my experience, sanity usually is the opposite of reality.
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Akaine Harga wrote:..The apps look nice, they require little coding, but they are slow. And with the Internet connection becoming faster each year people will start complaining more and more..

First do some measurements to confirm that it is really JSF which is slowing down your application rather than something else which won't become fixed when you stop using JSF.
 
E Armitage
Rancher
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Akaine Harga wrote:..
You mean I should forget about property binding and manually use jQuery for data fetching and view updates? And that without mentioning the stateless views. But wouldn't that multiply the required time for coding, code complexity in several times and render the best JSF's feature (variable binding) just useless? I'm not entirely against the idea, I just need time to get used to it, I guess.

As I said, you use that approach for pages that require that approach not for the whole application.
Akaine Harga wrote:
Actually, guys, one of the purposes of my post was exactly this:
Is JSF (or any other "automated" WebMVC) good for heavy views? Or am I actually hitting the limits here? I was considering to move to JavaFX8 for some time by now. As far as I understand I won't have any of these problem there. Or even forget Java completely and move to .Net SOA based apps. Because the idea of spending weeks of jQuery coding for a relatively simple functionality doesn't appeal to me as the most optimal (time/cost) solution.
Any thoughts?

I don't know what heavy views means here but generally JSF is very good for views where users capture data and you need to keep state in various scopes through their interaction. If your pages are only displaying data with no state being maintained e.g dashboard views, public websites, e.t.c then you are better off using stateless frameworks (JSF 2.2+ is trying to support more stateless paradigms as well but obviously not as mature as purely stateless frameworks). With any framework, the way you use it determines if you are going to spend weeks on technical code vs business logic.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!