Users running installations with many users, and with thousands of transactions per user, have reported poor performance: As the number of transactions grows, the plugin can become slow to respond. This is annoying for front-end users. In a way, the plugin is suffering from its own success.

Since version 6.0.0, the plugin is using the WordPress posts table on the MySQL DB (as well as the posts meta table) to store transactions. These tables can therefore become large and slow down the system.

The problem is mostly apparent in installations using the Airdrop or Exchange extensions. These two app extensions can create a large number of transactions in the plugin’s ledger.

Solution 1: Enable old transaction aggregation

A solution is to aggregate old internal transactions to save space and improve performance. In version 6.4.0 you can enable this in:

Settings → Bitcoin & Altcoin Wallets → ⌛ Cron tasks → 🗜 Old transaction aggregation.

For each user and for each currency, all such transactions older than the interval are grouped into one. This has the downside that some transaction history is lost, but the benefit is that the posts and post meta tables in the database will shrink significantly.

This is done on the cron job runs, with an optimized fast algorithm. The effect will gradually become apparent over the next hours/days, as the table sizes are reduced.

NOTICE: This transaction aggregation is NOT safe to perform if your database uses a non-transactional engine such as MyISAM. If this is the case in your installation, to ensure data integrity, the plugin will NOT perform aggregation. Most WordPress installations will be using a database with transactional InnoDB tables, in which case aggregation can be safely performed.

Solution 2: Deactivate and reactivate the plugin once, to create a post meta index that improves DB performance

Since version 6.4.0, on plugin activation, the plugin adds an index over the post meta table which greatly improves performance for this plugin. Before adding the index, a check is performed to see if such an index already exists.

If you have already installed the plugin and are upgrading to 6.4.0, deactivate (not uninstall) and then reactivate the plugin once. This will improve the response times of the WP-REST API, and therefore front-end performance.