Hi Alessandro,

This is not an issue coming from our Plugin, but rather, you are reaching the maximum load which your Hosting server can currently handle.

Our Plugin itself does not have any limits when it comes to how many rows or column you can create/or link to a Table from a data source.

However, regarding PHP limit options, there are limits coming from WordPress itself and from your Hosting Server configuration.

To mitigate this, if you reach the limits of what your Hosting server can handle, you can check what is the current PHP Memory limit and PHP TimeOut Limit and see if they can raise these limits for you.

You can check this in our System info tab of the dashboard.

Still, even if you raise these PHP limits as much as possible, WordPress itself also has some limitations.

To be more specific with your Query and data, I tried to count exactly how many columns you have in this SQL Query, I counted around 43 Columns.

When you check how many rows you have, and multiply that with columns, that is the total number of cells that try to load on your Page at the same time.

When your SQL Table has a lot of data, we have this server-side processing feature which can help to reduce hosting server load.

Please make sure you have this activated in your SQL Table.

Now, the default rows per page.

As you pointed out, this makes sense, if you are getting close to the limits of the Hosting server max load;

then we advise to keep this number as low as possible.

If it loads OK when you set 10 rows by default, I strongly advise to keep it this way and not allow users on front-end to go higher.

So, if you allow the users to have the 'Rows per page' dropdown on front-end, I advise to set up the custom number of available rows :

In that example, I set 1, 5 and 10 as the only available options - so a user can not go in front-end to choose 25 or higher.

I will advise more details, in case if this might be useful for your issue, these are general informations about slow load or freezing/crashing the page with a table :

The loading speed depends on a lot of factors - your hosting plan, server's performance, amount of other data on the page, internet speed, etc. 

For example, you can take a look at the table on our documentation, which contains around 2.600.000 rows, and see how it loads. The more data the table has, the more chance that it will impact the loading time.

Please note that Table is an SQL Query Based Table, it uses our Server-Side Processing feature, which dramatically improves loading speeds by using AJAX to only load one Table page at a time,

compared to non-server-side Tables which always load all rows on the HTML of the Page regardless of Table Pagination.

-

You can also check, in this table's filter settings for columns, how many unique filtering values there are.

If you have, for example - a string column that you set as a selectbox/multiselectbox, 

and if it has more than 50 possible filtering values,

you can go into that column setting, and check what is set for "Number of possible values to load" – 

Here you can define how many possible values per page will be loaded in selectbox filter and editor inputs. It is recommended not to be set for All if you have more than 50 possible values for this column.

So, check if that might be the case, try to lower the value to 50 and see if it helps the speed.

-

Also, it is possible for other plugins to affect the loading speed.

We had a couple of cases with users who have an "optimization plugin" with specific settings, 

such as  'SiteGround Optimizer', for example.

These plugins have certain settings that can negatively affect the performance of our tables.

If there is any JS minification going on,  there can be other settings, I can't say exactly,

but something to be aware of.

If you wish to do troubleshoot testing to check if an optimization/caching plugin might be slowing down tables,

you can try to disable all plugins and just leave wpDataTables active - then clear all cache and reload the page, see if it loads faster.

Then, if any optimization plugin Is used, try to revert all its settings to default, and if you use server-side tables ( such as SQL or Manual tables) ,  then please exclude the pages where you have tables from caching.

We have an issue if you use server-side processing combined with caching on the same Page - our devs are working to fix this in the future, we can't say an ETA - for the time being we have to exclude any Page from caching where we have tables with server-side processing activated.

-

Another thing to consider is how many 'Default rows per page' are set in the Display settings.

Try setting this as low as possible and test if that improves performance for that table.

I recommend it is best to use our new 'Custom rows per page', so if you allow front-end users to be able to use the dropdown for Rows per page on front-end, this will limit their options, to avoid loading 'All rows' and if you wish to get as much performance as possible, you can even remove the 100 and 50 options, or even 25 if that helps. 

-

Check if you have the "auto-refresh" enabled on the Tables.

If you have a large number of tables and enabled this at a high frequency, such as every 5 or 10 seconds, then the Hosting Server will often make Admin-Ajax calls from the Hosting Server to the SQL Database to pull the data, which can increase the server's load.

You can try disabling it and see if that helps.

-

Lastly, if you use an external Database connection ( not the default WordPress database), in some cases it can help the performance if you can move those SQL tables to pull them directly from the same DB where WordPress is on the Hosting server, so you can try that as well.

-

That is about all the advice i can give about this, but of course, let us know if you have additional questions.

Thank you

Hi Alessandro,

You can only try to enable WP_DEBUG on your Hosting server, then try to see if you can get more details about the error from the debug messages of the server.

Currently we do not have any error checking or Log which can show you more details about this error from our Plugin itself.

But based on previous experience, I can tell you, from the details you described how this happens;

This is most probably just reaching the limit of your Hosting server - it is not able to handle so many columns and rows when they load at the same time, when you increase the 'default rows per page' in the Display settings of the Table.

As you said, when you change from 10 to 25 - this increases the load on your Hosting server and WordPress so it goes over the limit of what it can handle.

I hope it helps, but we will be here to keep advising as much as possible, let us know if you discover any further useful details from your end.

Thank you.