Bug 1283304 - [ENG](6.2.z)Business central long initial loading time due to not cached js files
[ENG](6.2.z)Business central long initial loading time due to not cached js f...
Status: VERIFIED
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
6.1.0
Unspecified Unspecified
high Severity medium
: CR1
: 6.2.1
Assigned To: Christian Sadilek
Lukáš Petrovický
:
Depends On:
Blocks: 1288021 1288023 1295517
  Show dependency treegraph
 
Reported: 2015-11-18 11:33 EST by Maciej Swiderski
Modified: 2016-07-31 21:11 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1295517 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Maciej Swiderski 2015-11-18 11:33:42 EST
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):


How reproducible:
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:
1.
2.
3.

Actual results:
cache.js files are downloaded every time user logon

Expected results:
cache.js files should be downloaded only once

Additional info:
Comment 1 Maciej Swiderski 2015-11-18 11:36:05 EST
Assigning to Christian as he (and Mike) did most of the work on master:
https://github.com/uberfire/uberfire-extensions/commit/9b91985877bdceb76a1edd79af2fc368997e4056
https://github.com/droolsjbpm/kie-wb-distributions/commit/33415d4d38f73d233122913563c2bb3156dc14d7
https://github.com/droolsjbpm/kie-wb-distributions/commit/5f503888b134e77307e0834397b65633636fca4b

Christion, please double check if above commits are all that should be back ported to solve this issue.
Comment 3 Christian Sadilek 2015-11-18 11:46:06 EST
Yes, that's all the commits needed.
Comment 4 jbride@redhat.com 2015-11-18 14:31:14 EST
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.

Don't want to hijack this BZ but related:  would be nice to have a javascript widget that shows real-time download status.  Current status widget along with browser status (http://i64.tinypic.com/293bll3.jpg ) is OK but doesn't indicate how much of the download remains.  Sorry, not sure if an off-the-shelf js widget that can do this even exists.

Another related topic:  are the BPMN2 process designer javascript libraries configured to automatically get cached ?
Comment 7 Zuzana Krejčová 2016-01-20 10:29:42 EST
Maciej,
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).

Any advice?
Comment 8 Christian Sadilek 2016-01-20 11:30:19 EST
Hi Zuzana,

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

Cheers,
Christian
Comment 9 Christian Sadilek 2016-01-20 16:20:45 EST
Setting back flags that I changed by mistake.
Comment 10 Zuzana Krejčová 2016-01-21 04:03:54 EST
(In reply to Christian Sadilek from comment #8)
> ...

Thanks Christian!


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.
Comment 11 Zuzana Krejčová 2016-01-21 04:18:00 EST
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.
Comment 12 Christian Sadilek 2016-01-21 10:18:23 EST
Hi Zuzana,

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.
Comment 13 Zuzana Krejčová 2016-01-22 08:47:34 EST
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.

Note You need to log in before you can comment on or make changes to this bug.