Red Hat Bugzilla – Bug 1283304
[ENG](6.2.z)Business central long initial loading time due to not cached js files
Last modified: 2016-07-31 21:11:48 EDT
Description of problem:
There is rather long initial loading time for business central after logon - might not be visible too much on localhost or local network as it's rather fast but is really visible on slower networks.
Problem is caused by disabled caching of resources (*.cache.js) while they are perfectly cacheable.
when looking at network trace from the browser after logon you can notice hat every time around 7 MB js file is downloaded from the server while it should be downloaded only once.
Version-Release number of selected component (if applicable):
open network trace in the browser (like Chrome) and logon to business central - look at cache.js file being always downloaded instead of being served from cache after first use.
Steps to Reproduce:
cache.js files are downloaded every time user logon
cache.js files should be downloaded only once
Assigning to Christian as he (and Mike) did most of the work on master:
Christion, please double check if above commits are all that should be back ported to solve this issue.
Yes, that's all the commits needed.
Thank you for identifying this!
Turns out this actually becomes important in two use cases:
1) on-line training: Student lab environments for RHT's BPM enablement course (OPEN and SkillsExchange) is hosted in the cloud. First impression for these students brand new to BPM Suite is the initial log into their remote biz-central web app in the cloud. We instruct them to be patient but there is still a high temptation to press the refresh button in their browser as they wait for what turns out to be a 7MB download.
2) partners / customers who have shared BPM Suite dev / test environments in their private cloud. We are seeing more of this. Often times their private network is not great.
PRs sent for inclusion in 6.2:
Commits have been merged for 6.2 (product) on Dec, 8 (see links to PRs above):
perhaps I am simply doing something wrong, but I can't get it to *not* cache even with 6.2.0 or 6.1.0. I can't seem to reproduce the original issue (aside from ticking the 'disable cache' checkbox in dev.tools in chrome, obviously).
Here's a way to reproduce the original issue:
- Open the KIE workbench (6.2.1 deployed to WildFly) in Chrome
- Open Chrome's network tab
- Log in
- You will see the file 7BB030DE179602768998EA11C33CF308.cache.html being downloaded (~ 5.7MB)
- Refresh the page (without clearing the cache) or navigate to another page and back again
- You see the download happening again where in fact the file should have been cached
Setting back flags that I changed by mistake.
(In reply to Christian Sadilek from comment #8)
Hmm, yes, that's what I've been doing actually. Well, it gets cached even in 6.2.0 and 6.1.3 (but the Cache-Control is set to no-cache there). Or at least the behavior seems the same:
I'm filtering for '.cache'. On the first load, a few MB get downloaded (the HTTP status is 200), on refresh (or navigation somewhere else and back) there are only a few bytes (the HTTP status is 304 - not modified).
The loading time (from hitting refresh until the page is fully loaded) seems pretty much the same wheter I do a (soft) reload or empty cache and hard reload, even on 6.2.1.
I'm testing on EAP, not Wildfly, but that shouldn't make such a difference.
I'm a bit at a lost as to what to do here.
Scrath the loading time comment - I found the throttling feature in the developer tools. :) But even with that, the behavior is the same for 6.1.3 and 6.2.1 - long loading the first time, short(er) after refresh.
Please give WildFly a try. I did notice that the default behaviour is in fact different on EAP and WildFly. On WildFly and with 6.2.1 you should definitely be able to reproduce the original issue.
Since WildFly isn't supported by us, I verified that the relevant content is cached with 6.2.1 deployed to WAS, WLS, EAP, JWS.