Clarity

  • 1.  Server Side Cached HTML

    Posted Jun 12, 2017 09:01 AM

    Hi folks. Doing some performance analysis. We're finding high server processing for these "cache.html' files as shown below.

     

     

    This is probably a deeper digg into Architecture. Can anyone tell me more about these and/or this feature of the architecture? Ultimately, are near 20 second processing times for these expected? I hope/suspect not - would love to learn more about what I can do to mitigate or resolve this. I'll open a ticket if necessary - just wanted to start with some knowledge gathering.

     

    Nika_Hadzhikidi, nick_darlington, SumanPramanik



  • 2.  Re: Server Side Cached HTML

    Broadcom Employee
    Posted Jun 12, 2017 09:10 AM

    The GWT and /niku are the pages which are probably used all across the application and what you might see aggregated of all such actions show huge because all actions go via probably these pages. 

     

    For example 

     

    If multiple users access portfolio then everyone goes via these pages and upon aggregation it can show but. But is this the performance bottle neck, may be not.

     

    So we may need to gather heap when we see slowness and find out more. 

     

    Hope this helps Rob 

     

    Regards

    Suman Pramanik 



  • 3.  Re: Server Side Cached HTML

    Posted Jun 13, 2017 02:27 PM

    I'm pretty sure that those, and all the other items served up from the /ui folder, are delivered from the server to the client as static content (not processed server side).

     

    They will contain code, which in turn can pull other resources, that may give the appearance on the client side of taking up time, but there should not be significant time spent from the point of view of the server, and the app-access logs can help to confirm that (the time for the server to deliver them in ms should be present for each request, and is the total time from receipt of the request until the last byte was sent back out again).