Day#2 of #WordPress optimization
This time challenge is bigger, as I'm optimizing the @shoutmeloud database which somehow was closer to 1 GB, and that's why PHP workers on @kinsta are having a hard time ...

I definitely feel, Kinsta support should have pointed this out, but...

#Kinsta automated system suggested to increase the PHP workers, and I'm sure this might have fixed the issue for a bit, but not for long.

Here is an excellent guide by @kinsta on PHP worker: https://kinsta.com/knowledgebase/php-workers/#estimate-number-of-php-workers

& by @Pagely here https://pagely.com/blog/php-workers-wordpress-guide/

What I like about #Kinsta is they enable
@newrelic to find out the problematic #WordPress plugin/scripts, which definitely helps in diagnosing the issue.

However, they should also check the database size, as in a lot of cases, the bloated database is an issue. (feedback)

Before we dive deep into the optimization, here is the current config of @shoutmeloud

#Kinsta - Business 4 (Legacy plan)
#Cloudflare- Free plan
Plugin for performance:

1. #WP-Rocket
2. Flying Scripts
3. Asset cleanup

For reading: https://bit.ly/2TfTLKU 

#WordPress

Let's start by making sense of #Kinsta analytics. They offer detailed analytics, which is a good place to start.

Here is a good guide on #Kinsta analytics: https://bit.ly/36aXK0s 

So 25,308 times site has reached the limit within the last 30 days...

#PHP Workers are needed to handle PHP requests. If a request takes a very long time to be processed, this means other incoming requests cannot be served immediately. This can cause sites to be slower or can result in a timeout error in the worst case (shown as error 502 or 504)

So, in general: A lot of our readers have experienced "Slowness of the site" or worst case: 502 or 504 error

Apologies if you ever experienced slowness or such error in the past few weeks. This should have been fixed earlier.
Anyways, better late than never! #WordPress

So, there is a problem, and #Kinsta team has enabled #Newrelic and waiting for the next 30-40 minutes for the report to be generated.

However, I do feel the number of rows could be a reason...

#Database size is: 934 MB (Yesterday it was around 884 MB)..

Since the report is being generated using @Newrelic performance tool, I will hold on doing anything for the next 30 minutes.

I will start optimization after that... Feel free to chime in b/w & I'm open for suggestions.. :)

Will continue after a break..

Alright, so the report is out and it seems like there is one plugin that is being notorious.
To confirm #Kinsta team is running d test again on another #WordPress site of mine, using the same plugin

This should help us be sure of this "Notorious" plugin.. See ya after 40 minz

Alright, back in the game...
According to @kinsta support (You guys have done a great job today), the issue is with the external calls made by @socialsnaphq plugin. Here is the report :

I have notified the team behind SocialSnap, and they are looking into it..

Now, moving back to database optimization, and lowering down the number of rows (which is a lot currently)

This will unearth a lot of stuff, and probably you will also learn a lot from the next few tweets...

So grab a cup of coffee and let's do this...

#WordPress

So we need to lower down the size and also number of rows ..

a lot could be taken care of by Advanced Database Cleaner Plugin including orphan tables

https://www.shoutmeloud.com/wordpress-advanced-database-cleaner.html

and missed one, have to do manually... So heading to database

But, first thing first...
Always take a backup before tinkering with #WordPress database
with @kinsta taking manual backup is a breeze

You can also use this free plugin for DB backup https://www.shoutmeloud.com/wp-db-manager-plugin-wordpress-database-optimization.html

@blogVault too https://bit.ly/36bBCDr  (Paid)

So this "SEO_booster*" was added by a deleted, it is gone but left the stain in the database.

using d command to find, and delete them in bulk

SELECT FROM `wp_postmeta` WHERE meta_key LIKE '_wps_seo_booster%';
DELETE FROM `wp_postmeta` WHERE meta_key LIKE '_wps_seo_booster%';

Meanwhile "Query monitor" is a solid plugin to identify errors caused due to plugin or in codes

https://wordpress.org/plugins/query-monitor/

Found three slow queries, perhaps has to do with database size

Fixing database should help in fixing this .. Keeping fingers crossed!

When in doubt, simply copy the meta_key value in Google search, and you may be lucky to find a result , if you can't find anything, let it be.. Do not tinker with it...

**Deleted all inactive plugins (Kept some which I use on-demand)
** Deleting orphan table (For old sites, this makes a significant difference)
** Deleting orphan cron jobs

Repeating this, and then optimizing the database to see how this all works out..

We started from 934 MB

Here is an interesting plugin to control the cron jobs:

https://wordpress.org/plugins/wp-crontrol/

You can edit the cron jobs, and delete it, as long as you are not manually adding any cron jobs.

#WordPress