1

To sketch the background: I have a Glassfish 4.1 server running on JDK 7. On that glassfish are several applications deployed, each with it's own context root. There is a common library that is shared across the applications, and SSO is turned on, so the user only has to log in on one application.

The problem: When I open an application for the first time, it's very slow. It takes around 10 seconds to open a simple page (some basic database calls, a little JSF and some Javascript). After that, the page loads quickly (relative), around 700ms. So when a user then clicks on a link that redirects to another application, again, it's a long loading time.

So the possible sollution is that when the server starts, I log in and go and click on every page. Now the problem is, after a while, it starts to load slow again. I think it has to do with garbage collection, but I've increased the max heap size, max permgen, without effect.

What could be the cause of this and what could be the solution for this. I don't want to tell my users to just click and wait 10 seconds.

I've added what this question Measure the render time of a JSF view after a server request told me to do, and the results are weird:

FIRST CALL

create /content/index.xhtml: 6,167607ms
build /content/index.xhtml: 808,034825ms
render /content/index.xhtml: 1030,724281ms
create /content/index.xhtml: 0,935276ms
create /content/index.xhtml: 0,564929ms
build /content/index.xhtml: 207,870007ms
build /content/index.xhtml: 192,585271ms
build /content/index.xhtml: 18,823134ms
build /content/index.xhtml: 26,695793ms
render /content/index.xhtml: 2,928994ms
render /content/index.xhtml: 32,036747ms

Total: 2321 ms (rounded)

According to Google extension:
TCP Request: 3553ms
TCP Response: 864ms
Processing: 616ms
onload event: 7ms

Total: 5044ms


SECOND CALL

create /content/index.xhtml: 0,720167ms
build /content/index.xhtml: 127,220694ms
render /content/index.xhtml: 294,285362ms
create /content/index.xhtml: 0,748819ms
create /content/index.xhtml: 0,580752ms
build /content/index.xhtml: 152,104949ms
build /content/index.xhtml: 30,822214ms
build /content/index.xhtml: 224,347038ms
render /content/index.xhtml: 63,673639ms
build /content/index.xhtml: 9,347205ms

Total: 899 ms (rounded)

According to Google extension:
TCP Request: 178ms
TCP Response: 285ms
Processing: 477ms
onload event: 8ms

Total: 952ms

PostConstruct Render Time: 2569ms

Community
  • 1
  • 1
Erates
  • 646
  • 1
  • 9
  • 24
  • 1
    Measuring is knowing. Start here: http://stackoverflow.com/questions/33106118/measure-the-render-time-of-a-jsf-view-after-a-server-request/ – BalusC Dec 16 '15 at 15:23
  • @BalusC Will try that! – Erates Dec 16 '15 at 15:26
  • The weird call patterns suggest you keep rebuilding the very same index.xhtml view during a request. Are you somewhere repeatedly manually doing context.setViewRoot()? The high timings suggest very expensive business logic in @PostConstruct of a view scoped bean. Perhaps you're loading more data from DB than absolutely necessary for the particular request and you don't have a 2nd level JPA cache? – BalusC Dec 16 '15 at 16:20
  • I'm not calling context.setViewRoot(). I am using 2nd level JPA cache, but this particular page loads data from a webservice. (Most of the pages do actually). But now I've found where the problem lies, and I'm trying to fix it. The PostConstruct does some calling and I thought it was a cheap call, but it's not. – Erates Dec 17 '15 at 06:30
  • Then you should post this as an answer so the question can get marked as solved. – unwichtich Dec 28 '15 at 18:19

0 Answers0