Slow pages on first load

[ACS LLC]

[CF2016 - Windows Server 2022 - IIS 10]

I have a problem where if I replace a set of files, for instance 12 small CFM's and then I run one of them, it takes about 7 to 8 seconds for the page to load, then it's fine.

This does not appear to impact HTML pages, just CFM. It's not database related, I saved the static results of a page, and saved that as a CFM so there was no database queries and it still did it.

I never had a problem until I updated from Windows Server 2016 to 2022

I cloned the server and then installed a CF2023 trial so it made me think that perhaps CF2016 did not work well with Win2022/IIS 10. However, I then cloned it again, removed the CF2016 and reinstalled it, and it seems to be just fine.

So the fix looks like I have to take down the production server, uninstall and reinstall, but before I do that, I was wondering if anybody has any thoughts on anything I might check that could fix this?

Thanks

[Charlie Arehart]

So first, to make sure we're on the same page, you upgraded your windows server 2016 to 2022, in-place, right? You didn't install cf2016 on a new machine running Server 2022, right? And then you experienced this slowness with cf2016.

But then installing cf2023 or reinstalling cf2016 on that machine showed no such delay, right?

And you say the delay is on first load...of each given cfm page, such that a refresh of that page is instant right? Are you sure, though, that the refresh is not leveraging your browser cache? It may be. There's a big difference in the cause if it's really ONLY the first request vs EVERY request (every request that really gets to cf).

And I'm going to presume your issue is that EVERY request to cf is slowed. (There are multiple ways to detect or force the browser's use of its own caching or not.) 

One last question/presumption: are you experiencing the delay ONLY in pages requested through a web server like iis or apache? As opposed to a request made against cf's built-in web server (at port 8500, by default)? You can put a page in cf's cfusion/wwwroot folder to test. I'll assume it's NOT a problem there. 

As such, and since you feel it's ONLY after the windows upgrade yet GONE when you reinstall cf2016, I'm going to guess that it's the os changing something that differed from when you first installed cf2016 (created 8 years ago, and not updated since 2021--which I'll assume you understand is a grave security risk).

So my guess is a change (in the os) related to ipv4 vs ipv6 support, such that the configuration of how localhost resolves has changed from 127.0.0.1 to ::1. You could test that with a "ping localhost" at the command line on the server. 

And then the cf wsconfig tool creates its connector (in cf's config/wsconfig numbered folder), it puts the word localhost in the workers.properties file there. Then that's used to resolve a connection from the web server to cf (to tomcat underlying cf). 

Then there's a corresponding server.xml file (in cf's cfusion/runtime/conf) that has a line for the "ajp" (not "http") connector that the connector uses to talk to cf. That offers an optional address attribute to name what ip address can be used to call that connector. 

You could try changing that line in server.xml, but let's see if you just change the workers.properties instead from using localhost to using ::1. You don't need to restart cf, but only the web server (like iis). 

BTW, though you or others might think an "easier" solution would be to change the hosts file on your server to point localhost back to 127.0.0.1, I'd recommend against that--as it could have far more wide-ranging impact on things than the cf-specific change above. 

Let us know what you think or how it goes. 

[BKBK]

My guess of the cause: incompatibility between ColdFusion 2016 and the Windows Server 2022 Operating System. The server is probably too new for ColdFusion 2016. See the ColdFusion 2016 Support Matrix.

[Charlie Arehart]

While it's true that Cf 2016 formally does not support windows server 2022,  recall that he said that all was well when he reinstalled cf2016 on the machine. As such, that confirms there's a different problem than mere "incompatibility" due to it "not being supported".

And that's why I shared the other detail, though I realize you may not have read it, wanting only to make that reasonable observation. 

[ACS LLC]

Thanks for the input. It was several months ago I upgraded and I can't for the live of me remember if I managed to do it in-place, it looks like I did as my VM dashboard still thinks I am on Win2016. I have a recollation of some issues in upgrading but I can't remember what they were (I'd actually been very unwell with a serious condition and not long been out of hospital around the time so my memory is not great). 

I didn't try a local load of the pages, but yes, reinstalling in a cloned server did seem to fix the problem, suggesting something somewhere had changed. I wish could remember the series of events, but I am going to guess that I'd managed to install over the Win2016 and it changed something, then when I reinstalled it, it puts it back.

If that is true then it's likely a matter of time before it happens again, mix in that CF2016 has not been updated for 3 years and was not designed for Win2022 and it does not seem like a great idea to keep it around any longer than I need to.

With that being said, I decided the best thing is to upgrade. Choice being pay the big bucks for a CF license, or try (again) to get Lucee up and running. I went for the latter and after a similar performance issue managed to get it working fine (although it won't work on one of my sites but that's another story).

So, I am going to forge ahead with Lucee and hope that will be the end of my trouble

[Charlie Arehart]

And that similar performance issue in Lucee had a similar resolution, didn't it? For folks interested, here's his thread he opened yesterday on the lucee forums, where folks offered essentially the same answer I had:

https://dev.lucee.org/t/lucee-6-0-0-585-4-second-time-to-load-cfm-pages/13512/12

I'm just clarifying this to suggest that I was on the right track in my guess of what could solve it. But again, yes, wise to get off cf2016, whatever route you'd go.

As always, my focus was to solve your immediate problem (with context and clarification rather than merely "try this"). Not everyone is persuaded to move off their old cf versions, and I wanted first and foremost to solve that problem as you presented it. 

[ACS LLC]

I was not sure if I should post about Lucee in an Adobe forum 🙂

I actually had a couple of links, as I ended up contributing to a thread that had already addressed the issue. I did add a summary to both of the threads, but the one to look at is probably this one as it has a lot of info from others prior to me, and how I ended up with my fix

https://dev.lucee.org/t/performance-issue-with-lucee-ajp-and-iis/13390/19

I am looking forward to getting updates again!

I would have actually stuck with CF and purchased it if it was not so expensive.

[Charlie Arehart]

I think you meant to point to your previous msg in that thread:

https://dev.lucee.org/t/performance-issue-with-lucee-ajp-and-iis/13390/18

(FWIW, that was your reply to someone else's thread there from January, which was of course helpful for you to do. I pointed to the other thread above because it was your new thread there, from yesterday. I though that to be useful to point to in the context of readers following along here.)

And yes, like that your thread there from yesterday, in this other reply you now point to, you discussed there how (after learning from lucee folks) you had a choice of editing the boncode config file or the server.xml, to solve the ::1 problem. That's indeed just like I was saying about the workers.properties or the same server.xml file in cf. 

Again, bottom line is the change in your OS regarding ipv6 (::1 vs 127.0.0.1), affecting either cfml engine (and more). As always, I strive to help find that root cause.

And with either cfmk engine, we could argue the problem is really in tomcat. If it would properly accept calls from EITHER 127.0.0.1 OR ::1, people wouldn't end up in this pickle--on both engines.

Finally, I'd mentioned long ago (in the older lucee thread there, and still older ones) that another solution is for folks to create TWO connector lines, one with 127.0.0.1 and one with ::1. Again, tomcat should let us specify more than one address value, but it does not.

Again, just offering additional perspective as much for future readers. Glad you're sorted. 

[ACS LLC]

oh, my bad on the link. Well they are all in here now 🙂

It's a little disappointing that Tomcat does not have this sorted out of the box, but at least when you know how, the fix is actually quite simple.