Allegedly a server upgrade to CentOS 7

I had been running a few Centos 6 servers just past their EOL (30th November 2020) and it was time to kick in to action a plan I had been working on when I realised EOL was on my doorstep.

A month or so beforehand, I started researching options to upgrade to Centos 7.  Okay initially I wanted to jump Centos 7 and charge in to Centos 8 which had a planned EOL of 2029.  CentOS 8 had been stable for well over a year.  Not bad, closer to two years would have been better, but definitely worth looking into an 8 upgrade.  As a reference point, when I started on CentOS 6 it had been stable for just under two years.  However, that all changed when RHEL announced that 8 EOL was being brought forward by eight years to December 2021.  Yet Centos 7 remains supported until 2024.  CentOS Stream is now RHEL's focus.

Server configuration

The CentOS 7 server is running as a Linux Cloud VPS.

Note - 7.2 came in post the testing of 7.1.  This occurred once it was clear that the time issues were not related to resources such as RAM allocation.

Speed testing the servers

Initial testing on a freshly installed server Centos 7 showed:

• Server back ups automated or manual failed immediately.  This was corrected, however, on the next automated run they failed again;
• Performing what I would say was a simple command cp, I timed the old environment (Centos 6) against Centos 7.  The actual commands performed were:

All times indicated in the tables below are measured in minutes:seconds

command: yes | cp -rf 'stg/core' 'httpdocs'

The directory size is 109MB and number of files 21,059

command: yes | cp -rf 'stg/vendor' 'httpdocs'

The directory size is 53MB and number of files 5,435

command: yes | cp -rf 'stg/themes' 'httpdocs'

The directory size is 101MB and number of files 5,344

Note: time measured in mins:secs

From the third run the server configuration was upgraded to the reference 7.1 noted above.

Eventually the times on the CentOS 7 server (reference configuration 7.1) became more reasonable.  However, note that the core directory remained longer to complete than CentOS 6.  Showing 21 against 16 seconds respectively.

As you can see from the test runs above, slowly on the CentOS 7 server the execution times slowly came down.  Most within a second, except for the core that reach its lowest execution time of 21 seconds.  I now wanted to test if this was being influenced by caching or something else.

Further testing on a different domain and absolute path version 1

To further check on the speed of the server, I stopped working on the current domain and changed so it had quite a different absolute path.  This was to test the situation where there was a significant update in the code structure.  Therefore, not relying on the cache version of the code on the server.

command: yes | cp -rf 'stg/core' 'httpdocs'

The directory size is 53MB and number of files 5,435

command: yes | cp -rf 'stg/vendor' 'httpdocs'

The directory size is 53MB and number of files 5,435

command: ​​​​​​​​​​​​​​yes | cp -rf 'stg/themes' 'httpdocs'

The directory size is 101MB and number of files 5,344

Note: through out all of these tests I only ever ran two tests on CentOS 6.  This is because once the results reached below one second, there wasn't too much to be improved upon.

Changing domains and absolute paths version 2

On the second run, the times had dropped to less than a second.  This was true if I changed to a subdomain.  It seems the cache version was being held at the domain root path.  Once again it was time to change domains and test if the results were reliable.

command: yes | cp -rf 'stg/core' 'httpdocs'

The directory size is 53MB and number of files 5,435

command: yes | cp -rf 'stg/vendor' 'httpdocs'

The directory size is 53MB and number of files 5,435

command: ​​​​​​​​​​​​​​yes | cp -rf 'stg/themes' 'httpdocs'

The directory size is 101MB and number of files 5,344

As this stage, I'm seriously considering whether to persist with CentOS 7 and deep dive to establish the reason the execution times are so poor.  However, that could be potentially a big investment of time with little in return.  Essentially I come from a position that a new product should hit the ground running.  That does a superior job than the previous version.

Time has passed - any improvements?

Test date / time: 15 February 2021 @ 1 - 2pm

It has been a few weeks since the last check on using the cp command.  Well today I ran the test again and the results were:

command: yes | cp -rf 'stg/core' 'httpdocs'

The directory size is 53MB and number of files 5,435

command: yes | cp -rf 'stg/vendor' 'httpdocs'

The directory size is 53MB and number of files 5,435

command: ​​​​​​​​​​​​​​yes | cp -rf 'stg/themes' 'httpdocs'

The directory size is 101MB and number of files 5,344

More time has passed - any improvements?

Test date / time: 11 March 2021 @ 3 - 4pm

It has been a almost a month since the last check on using the cp command.  Well I ran the test again and the results were:

command: yes | cp -rf 'stg/core' 'httpdocs'

The directory size is 53MB and number of files 5,435

command: yes | cp -rf 'stg/vendor' 'httpdocs'

The directory size is 53MB and number of files 5,435

command: ​​​​​​​​​​​​​​yes | cp -rf 'stg/themes' 'httpdocs'

The directory size is 101MB and number of files 5,344

In comparison to the previous testing, these results are a significant decline.  In fairness, the browser speed has had significant gains.  This makes me question is it just Vanish camouflaging the results.  Clearly more testing is required.