erlendeide

Hi

Please do not run this kind of optimization in the background, you will not succeed at making this *not crash* any servers. You should remove the code, and replace it with a help page that allows people to do this manually if they want to, but it should not be part of anything that happens automatically in your plugin.

It’s not just an initial thing.

What OPTIMIZE TABLE does is to rebuild a table and it’s indexes from scratch when it is InnoDB. In the mean time, traffic is blocked. This is under no circumstances something that a plugin should trigger (or care about).

ANALYZE TABLE will recalculate index statistics, which usually has the same result – except from the storage that OPTIMIZE TABLE may free up. Performance-wise ANALYZE usually has the same effect as OPTIMIZE.

ANALYZE or OPTIMIZE are not tasks you’d like to run often, once a week should be considered often, while once every other month would be more than enough. We might do this as seldom as once per year for many of our own installations.

I assume this plugin also writes to it’s tables on every page load to collect the statistics. Any INSERT query will be queued/paused until OPTIMIZE is finished. In the mean the mean time, the plugin triggers both more OPTIMIZE queries and more INSERTS if traffic comes in.

It’s almost guaranteed to take down any site with some traffic.

• This reply was modified 4 years, 3 months ago by erlendeide.
• This reply was modified 4 years, 3 months ago by erlendeide.

Top. I think there is no need for the index unless you are doing a query with a similar condition under other circumstances, that are not supposed to be background tasks.

Queries that do not use indexes do not scale.

The postmeta table is often one of the largest and fastest growing tables for WooCommerce stores. There are a variety of plugins that add SELECT queries of the type “WHERE meta_value = 4234874”. Select queries are what is used in the frontend, and _not_ having this index means that any query like this will not use indexes, and will become slower for every row added in that table.

It is correct that update, delete and insert queries will become slightly more expensive, and also use a little more database storage. This cost is a no-brainer though when the gain is getting rid of queries in the front-end that are not using indexes.

Hi again,

Ofcourse you are right.

Our servers run nginx in front of apache, and nginx negotiates the SSL connection and will set HTTP:X-Forwarded-Proto = https, but $_SERVER[‘HTTPS’] will always be off because Apache runs without SSL behind the proxy.

I noticed the comment on the is_ssl page, which suggests force setting it (will probably work, but is not very elegant) by adding it to wp-config.php.

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') { $_SERVER['HTTPS'] = 'on'; }

I would have preferred a way where this test and forced assignment was just not necessary, how do other plugins handle this?

• This reply was modified 6 years, 6 months ago by erlendeide.

+1
You should definitely implement an option for using system cron like @dvershinin suggests. Running cron jobs over HTTP is risky and does not always work. Running through real cron gets rid of risks and possible limitations (like timeouts and memory limits for example).

• This reply was modified 6 years, 10 months ago by erlendeide.

These are warnings, but should be fixed for PHP7.2 compatibility:

wp-content/plugins/onesignal-free-web-push-notifications/onesignal-widget.php:46
wp-content/plugins/onesignal-free-web-push-notifications/onesignal-settings.php:122

Hi @treeflips!

We’ve made a ticket for ourselves to make sure this will be documented in the plugin in the future.

The short answer from top-of-mind is “View logs” is Servebolt-specific, and the Nginx cache feature for full page caching will require a certain setup of Nginx (simplecache enabled). Apart from that, optimizing tables, wp-cli commands and such should work.

Make sure to always keep backups of your database when running database optimizations, just in case!