[6.6.13] cas-overlay-template slow rendering of login page

571 views
Skip to first unread message

spfma...@e.mail.fr

unread,
Nov 2, 2023, 1:40:43 PM11/2/23
to cas-...@apereo.org
Hi,
 
I was planning to update our 6.4.2 instances to 6.6.13, when I discovered something strange : when the login page is called for the first time on a freshly launched browser (or after total cache cleaning), it takes ages to be rendered (over 20s). But all subsequent calls are fine as long as the browser is not restarted.
 
This has been experienced with Firefox, Chromium and Edge on both Linux and Windows.
 
Of course, everyting was fine with the current 6.4.2.
 
I order to investigate in a neutral context, I gave a try to the stock "apereo/cas:6.6.13" official Docker image and the problem also occurs.
As it is very easy to try different versions with Docker images, I did the same with "6.6.12" version : no problem at all, everything is fine from the beginning.
 
I also wanted to build it with my own configuration and additions, but I am a bit lost with releases, as "6.6.12" and "6.6.13" archives contain "7.0.0-SNAPSHOT" stuff.  The one tagged as "cas-overlay-template-20231031143146" is also "faulty" and as was not able to get any "6.6.12" archive or earlier.
 
Fortunately, I had downloaded a "6.6.10" release which is working correctly. In case of severe "updatemania", I can still deploy this one.
 
Using the web development tools to debug page rendering shows there is a huge amount of spent with JS inclusions with the "faulty" versions.
So I think there is something wrong with those JS librairies, as disabling JS in the browser allows the page to be rendered in a snap. But of course, it's not a viable option IRL unfortunately :-(
 
I can sound vain, but with more than one thousand users almost threatened with death if they don't switch off their computer every night, I don't want to expose ourselves to a support tickets storm saying "something is wrong with x or y application", just because morning login phase has become excessively slow :-)
 
Is there a workaround ? JS is definitely not my cup of tea so I have no idea how to fix that or what to replace.
 
Regards
 
 
 
 
 
 
 
 


FreeMail powered by mail.fr

Doug C

unread,
Nov 4, 2023, 2:45:54 AM11/4/23
to CAS Community, spfma...@e.mail.fr
I also experienced something like this when upgrading from 6.5.8 to 6.6.13.  When running 6.6.13, a number of .js files would not load due to a net::ERR_HTTP2_PROTOCOL_ERROR error.

After downgrading to 6.6.10, there were no errors.

I also attempted 6.6.11 and 6.6.12 and while there are no errors, it is also extremely slow to respond.  At least on the first page load for any of the configured service registries and the processing of their logins.  After that it speeds up but is overall slow compared to 6.6.10.

I noticed that the version of Tomcat increases with each release so I did a test of switching the tomcat-*.jar files in 6.6.10 with those distributed with 6.6.13; this switches from running Tomcat 9.0.78 to 9.0.81.  After doing so when I access the CAS login page, I again am unable to load a number of .js files due to the same error.

I then did a similar switch with 6.6.13 to downgrade Tomcat to 9.0.78.  After doing so there was no problem loading the .js files.  There was a slight quirk with what I believe is a custom label in my theme.

Now, this only seems to maybe address the issue of the .js files not loading.  There also appears to be a much slower initial response to page loads and a slightly slower continual response to page loads and login responses.

I would appreciate any thoughts on how to continue to troubleshooting what is happening.

Oh, one final note.  I did try out the latest 7.0.0 snapshot and found that the .js not loading is not a problem there but the slow response is.

Thanks!

Mohamed Amdouni

unread,
Nov 4, 2023, 1:25:23 PM11/4/23
to cas-...@apereo.org
Hello,

Could be related to http/2 multiplexing features.

Multiplexing should enhance performance but in some situations it does not (if the browser is not compatible etc)

I would try disabling http2 to confirm the root cause by setting.

server.http2.enabled=false


Best regards.

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/e3b20bdc-3920-4f10-8957-40603d34f297n%40apereo.org.

Doug C

unread,
Nov 4, 2023, 1:25:36 PM11/4/23
to CAS Community, spfma...@e.mail.fr
After a little more research I discovered that Tomcat 9.0.82 fixes the issue with static files not being served properly.  Here is the relevant section of the release notes:
  • Correct a regression in 9.0.81 that broke HTTP compression.
After switching out the tomcat jar files in 6.6.13 to use version 9.0.82 instead of 9.0.81, all static files are properly served again.  I'm actually not sure why CAS isn't already using this release since tomcatVersion=9.0.82 is set in gradle.properties for 6.6.13.

Still no progress on why CAS has become so much more sluggish though so any thoughts continue to be appreciated on troubleshooting that.

Thanks!

Doug C

unread,
Nov 4, 2023, 3:26:03 PM11/4/23
to CAS Community, Mohamed Amdouni
Thanks for the tip!

I gave it a try but it did not seem to change the behavior of static files not loading.  If it was intended in relation to the sluggish response it also did not have the desired effect.

Then I actually discovered that it was already disabled by default.

So, I will continue to rely on upgrading Tomcat to 9.0.82 to resolve the failed loading of the static files and keep researching what might be causing the sluggishness.  I continue to appreciate any further tips or suggestions.

Thanks!

Doug C

unread,
Nov 6, 2023, 5:21:39 PM11/6/23
to CAS Community
It turns out this behavior is caused by commit # 5736 (master branch commit # 5652).  That commit removed the default setting for server.tomcat.background-processor-delay.

server.tomcat.background-processor-delay=0s

Adding this setting back fixes the slow rendering issues.  Interestingly enough in the original commit to master branch there is a comment from mmoayyed about performance issues but then he and dima767 couldn't find any evidence of it occurring.  Unfortunately it seems that maybe that wasn't documented anywhere because this definitely has a significant performance impact both during the first page load and validating authentication using saml (such as providing login for Google).  I was experiencing a consistent 8-10 second delay that disappeared completely upon restoring the setting.

Again, the other issue of static files not loading also must be addressed by upgrading Tomcat to 9.0.82 to incorporate the fix to HTTP compression.

JakubFr

unread,
Nov 9, 2023, 9:40:02 AM11/9/23
to CAS Community, Doug C
Hello,
I have the same problem, the built docker container in version 6.6.13 is not working, because of tomcat 9.0.81. Any idea how to update tomcat to 9.0.82 without interfering much with the starter.tgz project?

Thanks
Dne pondělí 6. listopadu 2023 v 23:21:39 UTC+1 uživatel Doug C napsal:

Doug C

unread,
Nov 9, 2023, 9:41:42 PM11/9/23
to CAS Community, JakubFr
I followed the instructions provided by Jonathan Taylor in the following post minus the last section that had an error.


Jonathan provided a correction for the last section that had the error and it is in this post.


Note that in the CAS 6.6.13 build.gradle that the value of tomcatVersion=9.0.82 so you do not need to change that.

Reply all
Reply to author
Forward
0 new messages