Okay
  Public Ticket #3225212
Many requests 503
Closed

Comments

  • Rodolfo started the conversation

    Dear wpDataTables,

    a few days ago we had a lot of requests in 503 and the plugin blocked the whole site. We had to disable the plugin from host and re-enable it.
    Note that the entire site and database were working properly.
    Below is an example of the error:

    "POST /wp-admin/admin-ajax.php?action=get_wdtable&table_id=860 HTTP/2" 503 719 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
    31.198.**.*** - - [01/Feb/2023:16:42:45 +0100] "POST /wp-admin/admin-ajax.php?action=get_wdtable&table_id=795 HTTP/2" 503 719 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.0.0 Safari/537.36"
    

    Is there anything we can do to avoid this in the future?

    Thank you

  •  1,667
    Miloš replied

    Hi, Rodolfo 

    Thanks for reaching out to us

    -

    1. Can you please tell me which version of wpDataTables are you using - do you have the latest 5.3?

    2. This text you sent , is that the full error Log report from the server, from the moment the site crashed?

    If not, please ask your hosting provider if they can send you the full error Log.

    3. The error 503,

    in most situations, this means that you experienced a "PHP timeout error".

    What you can try is to increase the max_execution_time and max_input_time ( or in other words, to increase the timeout limit in php.ini file),

    -

    If you want to check what is the current configuration, you can either go to wpDataTables System Info tab, and check the PHP Time Limit,

    9618927547.png

    or you can go to the Tools/Site Health on your WordPress dashboard,  and go to Info/Server,

    check what is the current max_execution_time (PHP time limit)  and max_input_time :

    7205830522.png

    -

    If possible, also check what is the current PHP Memory limit, and see if you can increase that ( if possible), it might help.

    If you need help on increasing this value, please check this guide.

    -

    4. And if i understood, once your hosting has disabled the plugin and re-enabled it,

    now everything works again, including wpDataTables?

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  •   Rodolfo replied privately
  •  1,667
    Miloš replied

    Hi, Rodolfo 

    Thank you for the error report, our developers will take a look at it as quickly as possible.

    - Can we also check out the site's back-end settings and tables?

    Please provide me a temporary WP-admin (administrator) user for your site where this happens, so we could log in and take a look ‘from the inside’ as that’s the most efficient way to see and resolve the issue. 

    We do not interfere with any data or anything else except for the plugin (in case that’s a production version of the site), and of course, we do not provide login data to third parties. 

    You can write credentials here just check PRIVATE Reply so nobody can see them except us.

    -

    And if we wish to save time, it would be best to either create a Staging site or to send us a duplicator/cloned version, there we could conduct thorough troubleshooting there as well.

    Would you be able to provide us with a staging site, along with WP-admin (Administrator) user, FTP, and the database access ( either Url with credentials with PHPMyAdmin or cPanel)

    , so our developers can debug the plugin, and see what's going on?

    If you're not able to provide us with a staging site, can you clone your website?

    If yes - I'll ask you to install the Duplicator plugin. It will generate a couple of files that you can send me (along with the log-in credentials), and then I can create an exact copy of your website, see what the issue is and try to resolve it.

    The Duplicator plugin can export only up to 500MB of data, so if your site is bigger than that, please use the All-in-One WP Migration plugin.

    Please note that the files will be too large to attach to the ticket, so you can upload them via wetransfer.com and just send me the link.

    -

    Please let me know if you can change the values we mentioned on point #3,

     'max_execution_time' ( optimally to 300),

    and increase 'max_input_time'  ,

     optionally raising the PHP Memory limit can help ( unless if you already have it high as 1GB , but if it's 256 MB , try 512 MB, or if its on 512 MB, try raising it to 1GB if possible);

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  •   Miloš replied privately
  •   Rodolfo replied privately
  •  1,667
    Miloš replied

    Hi, Rodolfo 

    Thank you, i downloaded your duplicated file, and we will pass it to our 2nd level Team for testing.

    I will keep you posted, as soon as they report back i will pass their findings right away.

    In the meantime, please let me know if you notice an improvement in the behaviour, if the site stops crashing,

    since you increased the PHP settings, and we will also see if the previous plugin version does not cause that issue, etc.

    Could you also send me remote Admin credentials and the live site URL, i can check out the behaviour as well, at least to see these table ID's that are coming up in the error reports, but we won't change anything on the live site?

    Please provide me a temporary WP-admin (administrator) user for your site where this happens, so we could log in and take a look ‘from the inside’ as that’s the most efficient way to see and resolve the issue. 

    We do not interfere with any data or anything else except for the plugin (in case that’s a production version of the site), and of course, we do not provide login data to third parties. 

    You can write credentials here just check PRIVATE Reply so nobody can see them except us.


    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  •   Rodolfo replied privately
  •  1,667
    Miloš replied

    Hi, Rodolfo 

    My sincere apologies for all the waiting time.

    Thank you for the duplicator and the Live site access.

    I can see that you increased the PHP time out limit to 300 on the live site,

    and that you reverted it to 5.2.

    5744574815.png

    I will seek advice from our 2nd level Team to see what is the best next step going forward in troubleshooting issues with 5.3.

    I checked some of the tables from the error log, seems they are mostly SQL tables with just a few rows, not large data sets, so this is quite odd, i can't determine what's causing the issue yet.

    Thank you for your patience, i will report back as soon as possible,

    and in the meantime let me know how it looks on your end, is the live site more stable since you increased the PHP Time limit and reverted to 5.2.

    Thank you

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  • Rodolfo replied

    thanks Milos,

    anyway we had upgraded to version 5.3 a couple of weeks ago (can't remember from which version, maybe from 4.8). I don't know if it is a version-related problem. Fortunately the site crashed only twice. Since version 5.2 has been there, it hasn't done that. let's see

  •   Rodolfo replied privately
  •   Miloš replied privately
  •  1,667
    Miloš replied

    Hi, Rodolfo.

    Following up, we have an update from our devs.

    1. Can you please let us know which hosting provider are you using?

    2. Our devs might have an idea what's causing this, but still not 100% sure, they're conducting further investigation.

    Can you please try to edit one of your PHP files in the plugin files, on your FTP ( or hosting file manager) you can find it in this path :

    wp-content/plugins/wpdatatables/source/class.wdttools.php 

    around line 219 find this :

    "$agent = 'Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0';"

    and replace it with this :

    "$agent = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0';"

    They are still going to try working on the duplicated files, and I'll keep you posted on that,

    but in the meantime, if you can please try this and let me know if it fixes the issue?

    Thank you

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  •   Rodolfo replied privately
  •  1,667
    Miloš replied

    Hi, Rodolfo.

    Thank you for confirming that.

    Yes, i can see that you also set a remote MSSQL connection in the plugin settings, did not check that before, and i passed these informations to our developers.

    I will keep you posted from our end,  and let me know if editing of that line of code helps to prevent further crashes.

    Thank you

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  •   Miloš replied privately
  •   Rodolfo replied privately
  •   Miloš replied privately
  •  1,667
    Miloš replied

    Hi, Rodolfo.

    Our senior developers have advised us on this additionally in the meantime.

    Since you don't have too many rows in your SQL tables ( not more than couple thousand rows per table),

    you can disable server-side processing on the tables, in their Data tab,

    and this should help with the loading performance and avoid crashes at the same time.

    This behaviour is not related to the plugin version, so you should be able to update the plugin again to 5.3 / latest version, and purge all cache on site.

    Let me know if disabling server-side processing in your SQL based tables helps.

    Thank you.

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  • Rodolfo replied

    Hi Milos,

    I installed version 5.3 and the site instantly crashed. I deactivated the plugin and reactivated and now the site works.

    I tried this modification:

    "$agent = 'Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0';"
    

    and replace it with this :

    "$agent = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0';"

    but I can't find the line to replace. Was it related only to version 5.2?


    In addition, I tried to remove "server side processing", but when I save the setting the flag comes back on automatically

  •  1,667
    Miloš replied

    Hi, Rodolfo.

    My apology, our senior developers confirmed that you should ignore that code workaround which we sent before - that will not help with this issue.

    -

    In regards to disabling the server-side processing,

    if i understood, when you tried it on an SQL table - it does not "accept" to stay disabled, right?

    Perhaps that table has more than 2 thousand rows.

    Can you tell me the table ID, or ID's if this happens on multiple tables, so we can inspect them as well?

    And if it would be possible to send us another Error Log report from the time when this recent crash of the site happened,

    if you have it or if you could ask the hosting support if they could provide it?

    Thank you.

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  •   Rodolfo replied privately
  •  1,667
    Miloš replied

    Hi, Rodolfo.

    Yes. For tables that have more than around 2000 rows, our plugin does not allow to disable server-side processing,  because for such large data sets, the page would become too slow or crash the page otherwise...

    We will do our best to find a solution as quickly as possible.

    Thank you for the latest error Log, we passed it to our developers again and they are looking into it.

    I will report back as soon as they advise.

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  •   Rodolfo replied privately
  •   Rodolfo replied privately
  •  1,667
    Miloš replied

    Hi, Rodolfo.

    I have another update from our developers, they have advised us.

    The main issue is most probably the sheer amount of data that is trying to be loaded all at the same time,

    due to the display length, which is set for the default number of rows to load on tables.

    We notice you have some tables with this setting to "ALL" rows.

    2333199077.png


    But also due to the SQL Queries that our SQL Parser needs to process.

    So, on the front-end , in the HTML of the page, if a couple thousand rows load at the same time for each table and it seems that the server is not able to handle all this data.

    -

    We propose to make a performance test, with the following modifications for all tables, 

     let's see if that helps, then this will conclude where the issue is coming from 

    For each of these tables, please set the 'default rows per page' to 10, and enable Server-side processing on every table.

    1107806261.png

    -

    If the crashes stop after that, and you are able to load the data on pages,

    this means that the issue is with the hosting WordPress server not being able to handle the amount of data,

    when you set the number of rows to "ALL" for tables.

    Let me know how it goes, we will closely follow the case.

    Thank you.

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  •  1,667
    Miloš replied

    Hi, Rodolfo.

    And i just forgot to comment about the update question.

    Yes, you should update to 5.4 ,   and we will closely follow the case, let me know how it goes.

    In regards to the  turboThreshold chart callbacks, i would not worry about that - it should not have effect on the crashing issues.

    Thank you.

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  • Rodolfo replied

    Hi Milos,

    instead of setting "the last 10 rows" I could set in the date filter for example "show data from 2023". The result should be the same (greatly reduce the number of rows show), but it would be more convenient for clients to change the number of rows, because they would just have to change the date filter and not the date filter+the "display" filter

  •  1,667
    Miloš replied

    Hi, Rodolfo.

    I asked our developers about this idea.

    Basically, they agree with you, but for example, if a user clears the filter on the front-end,

    and in this way, it will change the row number display length to "ALL" , which will most probably cause the site to crash again.

    - If you would filter directly through the SQL Query of the table to only load rows for year 2023, 

    and if that would return a drastically fewer number of rows, in that case, you would not have to set either a predefined filter nor the row display length.

    You can, of course, decide what to do, and we will be here to follow the situtation.

    Let us know how it goes. Thank you.

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  • Rodolfo replied

    We need to leave the possibility for clients to be able to view all data even from many years ago. So we can set a small filter by default, but leave the option to remove it. Therefore, I thought about setting a default date filter.

  •  1,667
    Miloš replied

    Hi, Rodolfo.

    Technically speaking, if we set a smaller number of rows per page,

    that only creates pagination in the table,  but all the data is still visible/accessible.

    So when we use a filter, if all the resulting data/all rows do not fit on one table page,

    a user can still go through several pages to see all the filtered data.

    Our server-side processing feature is made by our developers for these kinds of situations

    when a table reaches a certain data load that a specific server can not handle.

    Then our server-side processing loads only a smaller number of rows using Admin-Ajax calls,

    instead of loading all rows at the same time - which, in your situation, causes the site to crash.

    -

    So, you can certainly try your idea, to leave the default rows per table page to "ALL",

    but there is a big possibility that if a user uses a filter on the front-end that will load, for example around two thousand rows;

    and if you set the row number per page to "ALL",  then all 2 thousand rows are going to be loaded by HTML on the page at the same time,  which will most likely cause the site to crash.

    -

    But, as we said - see if another crash happens when you do that,  then you can try our suggestion, to reduce the default number of rows per table page,

    then if a user tries a filter that returns 2 thousand rows - the table will create pagination in order to "split the load" to load lesser data size to decrease the WordPress hosting server load,

    the user will still be able to see all the data, the rows will just be split to pages.

    -

    I hope this helps. Let us know how it goes. Thank you.

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  • Rodolfo replied

    Dear Milos,

    sorry but some of your points are not clear to me. Would it be possible to set up a call on Google Meet or Skype so that some points could be clarified?

    Today being Sunday, I tried to do a test: I opened at the same time 20/30 browser tabs of pages with tables having thousands of rows and had no problem loading.

  •  1,667
    Miloš replied

    Hi, Rodolfo.

    As our developers explained on this documentation about large SQL tables on this page;

    i will quote the most important part here :

    When your data set is larger than a couple of thousand rows

    it can’t effectively be loaded onto the page from data sources.

    Each of these methods first reads the data from the source, 

    and then prints out the complete table data on your page; 

    so, as the row count grows, it makes both the page generation time on the server side and the page load and initialization time on the client side, slower and slower.

     If your host server has a certain memory or timeout limit defined for PHP scripts, it can ‘break’ the page, because the script would try to allocate more memory than it’s allowed.

    -

    This is why our developers created the server-side processing, for situations where server would crash due to too many rows loading on page at the same time, we reduce the default number of rows from "ALL" to anything else, at least "100" or less, to reduce the server load.

    You can see more details explained about server-side processing here.

    -

    If i understood, now you have tested to open several pages at same time ,20 to 30  pages,

    and loaded thousands of rows on them by choosing "ALL" rows on tables and it did not crash the site?

    If that is the case, i am honestly not sure - perhaps the hosting have upgraded some performance of your hosting server,

    but if the crashes completely stopped, then it seems the issue somehow resolved itself.

    -

    You can certainly try to just do your idea to reduce the default loaded rows by the initial date/year filtering,

    and see if that helps.  If the crashing stops, that is what's most important.

    But if you notice any crashing again,  you can decide, if you wish to try to change the default number of rows loaded for tables from "ALL" to anything else, like "100" or less, to see if it helps.

    Let us know how it goes.

    -

    In regarding to live call or meeting - i am sorry but our support is not able to provide this, we can only help through our ticketing system.

    Thank you.

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  •   Rodolfo replied privately
  •  1,667
    Miloš replied

    Hi, Rodolfo.

    Thank you for this update and the Error Log.

    1. I will reach out to our developers to see if they have any further advice other than what they already said before,

    they will check this latest Log as well.

    I see that you still have the 'Default rows per page' on all tables to "All" in the Display settings,

    but so far all these tables i am checking have a very small number of rows - can't find any that have a large row number from the Error Log.

    5743566149.png

    I did notice that you also set the Auto-Refresh to around 5 seconds for all tables as well,

    ( at least the ones i checked so far)

    and I see that you are calling all the SQL tables from an external DB connection.

    Not sure if that might be relevant, we will check it as well, to be safe.

    9047906952.png


    2. I am going through all the folders of our plugin files, as far as i can see, there is no folder named "wp-views".

    If you check in your WordPress hosting folder on the server,

    you should see this path to our plugin :

    ..\wp-content\plugins\wpdatatables

    In other words, "wpdatatables" is the name of our plugin folder.

    That one "wp-views" is probably another plugin's folder.



    3. 'Isn't there a way to say "if after 5 calls the table doesn't load, try again after ** seconds" so it doesn't crash?'

    I don't think that we have something like that function available, but i will also check that with our devs.


    4. Yes, the PHP version 7.3.33 is OK.  Our plugin is being optimised up to PHP 8.1.13 , 

    so that should not cause any issue.


    5. The only advice i can say at the moment personally is, 

     because our developers already tried to advise before to do a test for a couple of days to try and set up all tables to have a much lower default row number in the Display settings,  

    to try set it to "10" rows by default,  this way you could perform a test to check if that is causing the crashes,

    if the crashes stop for a couple of days - at least we could get a conclusion in that regard;

    but i will reach out to our developers to take another look at everything, and will report back as soon as they advice.

    Let me know if you try their previous advice in the meantime.

    Thank you for your patience.

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  •   Rodolfo replied privately
  •  1,667
    Miloš replied

    Hi, Rodolfo.

    Our developers went through everything and advised.

    I will share their explanation and assessment of the situation,

    as well as a couple of things you can try to see if it helps.

    -

    All of the tables which are appearing in the Error Log are SQL tables pulling data from the Separate/external Database connection.

    And as you said, the fact that these crashes do not happen all the time, but in certain moments,

    it means that our plugin is functioning as it should be,

    the issue is coming from the server side,  it seems the server is not capable of handling certain situations,

    at least not with the current way how the tables are configured / the calls that are happening towards the server.

    -

    In the moments when the error 503 gets thrown, most likely something "breaks" on the server side,

    or in other words with the connection to that external Database.

    Also, you have the auto-refresh enabled approximately at every 5 seconds on certain tables;

    which means that for those tables , at every 5 seconds a call is being sent towards the server to return data.

    That is something that we are not able to handle or affect from our end.

    -

    Now, the advise on what you could try to see if it helps.

    1. They suggest that you can try to move these SQL tables to the same database where your WordPress is,

    and you can try with all the same settings + auto-refresh.

    If the behaviour stays the same, it means that the server is not able to handle this many requests in a short period of time.

    -

    We also do not know if you placed several tables on same page,

    if that is the case, the more tables you put on same page together,  it will be more calls to the server from the separate DB connection. 


    2.  Another way you can try is,

    try to disable server-side processing if you move the tables to the same Database from WordPress.

    This will cause disabling "auto refresh" feature,  so the data from the table(s) will update only on page refresh with the latest data;

    but it also means there will be no calls towards the server;


    Let us know how it goes, we hope that helps.

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  •   Rodolfo replied privately
  •   Miloš replied privately
  •   Rodolfo replied privately
  •   Miloš replied privately
  •   Miloš replied privately
  •   Rodolfo replied privately
  •   Miloš replied privately
  •  1,667
    Miloš replied

    Hi, Rodolfo.

    We have been advised by our senior Team.

    1. In regards to not being able to search/filter on the SQL Query Table as 'commodit_tables.RT_Energy_Products' :

    This will not be possible in that way.  If you separate the table name and database with a dot,

    like "databaseName.TableName"

    it can probably pull the data from the SQL table,  but you won't be able to filter or search,

    and there is a chance for some tables that they won't even pull the data.


    2. If you change the database from which you are pulling the SQL tables,

    you will have to add this Database as another "Separate DB Connection" in the main plugin settings.

    Even if it is on the same server as your WordPress Database, our plugin still treats it as "another database",

    so you have to add its connection like that.


    3. And you will have to copy all SQL Tables to that database, in order for our plugin to access them.

    I hope that helps.

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  •   Rodolfo replied privately
  •   Miloš replied privately
  •   Miloš replied privately
  •  1,667
    Miloš replied

    Hi, Rodolfo.

    We got advised by our devs.

    Basically, this server is not able to handle the server-side processing enabled with auto-refresh option combined together.

    It causes too many calls to the server with the data from tables.

    -

    If you set all the default rows in the Display setting of tables, then a request towards the server is being sent for all the data from the tables.

    -

    If it is set to "All" rows, there is a Query like that in the background/ back-end code that is being "generated/packed" and is being called at every 5 to 7 seconds.

    What  you can try is, ( if we haven't tried that before already) is to disable server-side processing in the SQL Tables and follow to see if you get any issues with that in the following period.

    It should be fine if you do not have tables with very large data sets.

     If your SQL query based tables are not bigger than 2.000 rows, 

    you can disable server-side on SQL tables, and it will work like it does for Excel tables. ( loads all rows)

    If you need to increase the row count while still having the "toggle" to disable server-side,

    Please go to 

    ../wp-content/plugins/wpdatatables/source/class.wpdatatable.php

     and around line 2176 you'll see this:

    if (count($res_dataRows) > 2000) {

    You can change that number to a value bigger than the number of rows in your table.

    Same should be applied in

     ../wp-content/plugins/wpdatatables/source/class.wdtconfigcontroller.php on lines 53:

    if (count($wpDataTable->getDataRows()) > 2000) {
    

    And line 100:

    if (count($wpDataTable->getDataRows()) > 2000) {
    

    That will increase the server-side automatic limit.

    We hope this helps.

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  • Rodolfo replied

    Hi Milos,
    no problem, thanks for the support.

    yes I changed the PHP limit to 1GB a week ago. Since then we have not experienced any crashes.

    I forgot to tell you that the 10/15 tables with autorefresh of 5 seconds contain maximum 15 rows. If I de-select the "server-side" it is no longer possible to select autorefresh, so these tables must remain as is.

    As for the other tables (without autorefresh) do you then recommend increasing the limit (e.g., 10,000) and removing the "server-side"?

    For your information, our server that hosts the site and also the database is a semi-dedicated server with:

    4GB RAM
    4 CPU
    40MB/s IO
    35 Processes

  •  1,667
    Miloš replied

    Hi, Rodolfo.

    Firstly, I would like to sincerely apologize for the delayed response as we have been experiencing an unusually high number of tickets. I am sorry that it has taken longer than usual to respond to your concern and your patience is highly appreciated.

    -

    1. I am glad to hear that increasing the PHP Limit helped with the crashing.

    2. In regards to auto-refresh,

    yes - the tables are still going to update any changes you make on the table, but the page needs to refresh / or load in order to show the updated table.

    For the larger tables, such as if any tables have 10 thousand rows or more,

    you can first make a backup of the site for safety, because such large data set with server-side disabled might crash the page.

    For any data set larger than 5 thousand rows approximately, it Is recommended to enable server-side processing,

    so for such large tables you can try with server-side, but maybe disabled auto-refresh,

    to decrease the number of calls towards the server.

    -

    In either case, you can try like that, or completely disable server-side and see how the server handles it.

    We will be here if you need further advice.

    Thank you.

    Kind Regards, 

    Miloš Jovanović
    [email protected]

    Rate my support

    wpDataTables: FAQ | Facebook | Twitter | InstagramFront-end and back-end demo | Docs

    Amelia: FAQ | Facebook | Twitter | InstagramAmelia demo sites | Docs | Discord Community

    You can try wpDataTables add-ons before purchasing on these sandbox sites:

    Powerful Filters | Gravity Forms Integration for wpDataTables | Formidable Forms Integration for wpDataTables | Master-Detail Tables

  •   Rodolfo replied privately
  •   Miloš replied privately