I never work with Wordpress but not because I don't like it, but because I know Joomla back and forth and I develop faster here.
I got a message from a friend who couldn't access the wp-admin site, it was a blank screen. I went to SSH and ran lynx and curl to get the index.php of the wp-admin folder and I was getting redirected from a www domain to a non-www domain. So far it looked like DNS, but it wasn't.
We disabled plugins and verified code. It wasn't the way.
After several hours, I took out the site url value of the table 'options' and ran the wp-admin to get an error about database connection with a 500 error code. Then I added the line define('WP_ALLOW_REPAIR', true); to wp-config.php and it prompted me for an autorepair feature that wordpress has and returned the "site url" value to the 'options' table and it worked. 4 paragraphs that took 16 hours (that happens when you don't know what you are doing hahaha)
If you are using Varnish and Cpanel, you might have to check this.
By default, the configuration file is located at /etc/sysconfig/varnish but I couldn't find it anywhere. If you can't find it as me, look for varnish.params at /etc/varnish
I'll update this post later
I spend the last 7 days looking for a way to lower the Time To First Byte (TTFB) on a website. It was taking from 79 to 90 seconds everytime you loaded the site for the first time.
My site is configured with:
- PHP 7
- Apache 2 + gzip + mod_ssl + mod_pagespeed + memcached. Pagespeed using memcached too.
- OpenSSL + a Comodo certificate
- 10GB Ram + enough hdd space
After the first load, the site was loading extremely fast in less than 3 seconds.
It wasn't the server. It was the Joomla configuration. I also had the JCH Optimize plugin to compress everything but I wasn't paying attention that on the first load, the site was packing all the images before displaying the site. I had to enable the images lazy load option to load the whole page and then the images.
After this change, times dropped to an average of 10 seconds on the first load then about 3 seconds on internal pages as you were navigating the site. This worked for some weeks but the server kept failing.
I had to disable JUX Social Counter module that was used to show live numbers of our social media pages. This was the real cause of the long TTFB.
Third run (final):
I changed hosting provider to Knownhost, changed Apache for Litespeed with cache and changed the database to MariaDB. Loading times dropped from 30s. to less than 5s. with the same load.
TTFB on a Joomla site with an average of 6k visitors a day with more than 100k articles on database can bring some problems you won't experiment on development or with a small server. Plugins start to play an important role on loading time, if you have outdated plugins it's better to update them to latest version.
Memory, configuration, modules, compression it all plays a role here. I found that switching to a SSD hosting with cpanel (Knownhost I really recommend this) reduced the loading time and general response to less than a third.
I decided to test Litespeed webserver + litespeed cache (there's a tweak you have to do to use it with Joomla) because I was tired of configuring apache back and forth. It really worked fast and stable.
When you have a lot of content, databases need to be optimized too. Mysql is the default but it's joins aren't as good as MariaDB. It's an easy upgrade with a WHM+Cpanel hosting. This was the final trick.
memcached, Joomla, TTFB, Centos, PHP, pagespeed, JCH Optimize, Jux Social Counter, litespeed, cpanel, whm, mariadb
Yootheme pro is not widgetkit.
If you ever find yourself creating the Google Map API (you can create it here) so you can change the hue and colors of the YooTheme PRO map, don't go to the widgetkit options. Instead, go directly to your Yootheme Pro's Site Builder and go straight to Settings->Advanced and scroll down to put your API Key under Google Maps. I found it is labeled too as "Google Fonts" but if you put the API there, it will work.
memcached starts but it stops immediately.
When running status, it says
memcached dead but pid file exists and when running
ps aux | grep memcached you can't see the pid file to kill it.
On CentOS you can go to /etc/sysconfig/memcached and check your configuration. In my case I had a redundant directive at the OPTIONS line where I was redeclaring the port. This is my memcached config file now.