• Resolved BeHeard

    (@beheard)


    Hi Tobias.
    We have an issue where in using large tables backend causes major resource hogging.
    VPS Account suspended today because working on large table caused major resource spike..
    After much back and forth the issue was traced to Tablepress (known resource user) appears a large table being worked on – spawns thousands of php processes, followed by the wordpress backend natural refresh = major resource spike.

    Is there any thought to look at this backend issue, without a resource backend issue fix – we will have to remove tablepress
    and I LOVE tablepress.

    http://wordpress.org/plugins/tablepress/

Viewing 13 replies - 1 through 13 (of 13 total)
  • Plugin Author TobiasBg

    (@tobiasbg)

    Hi,

    thanks for your post, and sorry for the trouble.

    To be honest, I have no idea what could be causing this, and I don’t really think that TablePress is responsible for this all by itself.
    TablePress definitely does not spawn own PHP processes, so I have no idea what’s happening there.

    It is however possible that very, very large tables in TablePress could cause resource problems, which will lead to a lot of PHP memory being used. However, that usually ends in the PHP Memory Limit being reached, which again results in an error message being raised.
    So, do you have very many or very large TablePress tables on your site? How many tables do you have, and how big are the biggest ones?

    Can you maybe try to find more technical information about this, e.g. in log files or from your webhost company? How did they come to the conclusion that this is TablePress’s fault?

    Regards,
    Tobias

    Thread Starter BeHeard

    (@beheard)

    Yes – quote from the server tech – the issue relates to the process that tablepress uses to access via the backend.
    I did ask what and how as it was a widely used plugin – he acknowledged this and said they are aware of it and it is also a resource hog in some instances..
    and it relates to how the data is being processed.

    Have at present 3 x large tables – 2450 rows X 10 columns (not exactly but that the largest one.
    it was one of these tables being edited. Was adding something to a row which caused this particular issue.

    Tech advised it appears to refresh with each and every entry so all of the data is refreshing with every move or mouse click.
    Will have a look at log files and post if possible

    Plugin Author TobiasBg

    (@tobiasbg)

    Hi,

    ok, thanks for that extra information. Unfortunately that still doesn’t really make things “click” for me.

    The method for the backend access is pretty straightforward, and the same that WordPress or all other plugins use. TablePress retrieves data from the database and displays it on the page.

    Also, I can’t see how the actual process of editing tables (moving the mouse or clicking, as you say) could influence this. All of that editing is done in JavaScript, in the browser on the client side. Only when the user clicks the “Save” button, an AJAX request is fired with the table contents, that are then saved again to the database. That’s also commonly used and straightforward. The difference to other plugins might be that the amount of data is bigger (especially in those large tables). But even that should not cause too much trouble on the server, as the worst case would be that the PHP Memory Limit is reached, as explained above.

    Now, those large tables of 2450×10 columns are rather large, and it’s probably not fun to work with those on the “Edit” screen (as everything will feel kind of slow), but they should not cause trouble on the server. If they do, I can only suggest to not manage these three large tables in TablePress, but to use a custom PHP/mySQL solution for them.

    Regards,
    Tobias

    Thread Starter BeHeard

    (@beheard)

    Just letting you know we are still working on what is causing this issue,

    There is another – Events – plugin we use that had a bug – ◾Changed some SQL that could trigger a MySQL bug involving an infinite loop”

    and they are again looking at it in case there is something that was missed.
    The logs show lots of tablepress actions and perhaps it picks up the action first.. will let you know any updates..

    thanks again

    Plugin Author TobiasBg

    (@tobiasbg)

    Hi,

    thanks for the update! Good to hear that you are making progress on finding the cause for this!
    If you find something wrong in that regard in TablePress, please don’t hesitate to contact me!

    Regards,
    Tobias

    Thread Starter BeHeard

    (@beheard)

    Again in another area (minifying scripts_)
    Tablepress is showing this error
    and stops IE – with a long running script.
    Am unsure if its a combination of plugins but use what I do in many sites just cannot identify what the problem is here.
    This is a large table and using esplayer and EDD for payment option in 2 separate cells.

    Plugin Author TobiasBg

    (@tobiasbg)

    Hi,

    I have no idea what’s going on there, but it’s not TablePress. Some other plugin (likely that minification plugin) is loading the actual JS files into the page, as it seems, but that doesn’t make sense.
    And when it does that, it’s not loading the jQuery JavaScript library, which however is a requirement for the DataTables JS library.
    Unless you see this on the site’s frontend (i.e. on a page where there is a table), there’s nothing that I can do here. This problem needs to be fixed in that minification plugin.

    Regards,
    Tobias

    Thread Starter BeHeard

    (@beheard)

    The minify plugin tidys script and css and cannot do that with any page that has tablepress at present.
    Turning off the minify plugin provides this JS error in Chrome..
    Not sure if it relates to tablepress though the viewport error only shows on pages that have tablepress..

    Hopefully getting closer to an answer..

    Viewport argument value “device-width;” for key “width” is invalid, and has been ignored. Note that ‘;’ is not a separator in viewport values. The list should be comma-separated. /about-2/:6
    Viewport argument value “1.0;” for key “initial-scale” was truncated to its numeric prefix. Note that ‘;’ is not a separator in viewport values. The list should be comma-separated. /about-2/:6
    Viewport argument value “1.0;” for key “maximum-scale” was truncated to its numeric prefix. Note that ‘;’ is not a separator in viewport values. The list should be comma-separated. /about-2/:6
    Viewport argument value “0;” for key “user-scalable” was truncated to its numeric prefix. Note that ‘;’ is not a separator in viewport values. The list should be comma-separated. /about-2/:6
    Resource interpreted as Font but transferred with MIME type application/x-font-woff: “data:application/x-font-woff;base64,d09GRgABAAAAAAXYAAwAAAAACXwAAQAAAAAAAAA…YV5efF56SmlfDCOEWZ6RklXMmJRakl8Sn55XkcEGZpAVQMpJgbwgQrZSnOLyoBACnGHqgAAAA=”.
    Resource interpreted as Font but transferred with MIME type application/x-font-woff:

    Plugin Author TobiasBg

    (@tobiasbg)

    Hi,

    that viewport stuff is coming from your theme, and not from TablePress.
    You’ll find the relevant line in the header.php, where you should change the ; to ,.

    The issue with the font is irrelevant here, and has nothing to do with the JS.

    Can you please post a link to a page where I can directly experience the errors?

    Regards,
    Tobias

    Thread Starter BeHeard

    (@beheard)

    Thanks again.
    Am working on it, remain uncertain if it is constantly picking up Tablepress in the js or if it does relate to it.
    Will keep tidying up can see no more errors but the minify plugin errors out with any page that has tablepress.
    He is looking at it so will let you know as soon as he responds

    Plugin Author TobiasBg

    (@tobiasbg)

    Hi,

    ok, that sounds good. Please let me know if you find anything!

    Regards,
    Tobias

    Thread Starter BeHeard

    (@beheard)

    Working our way through.

    Can you advise – ie page load shows around 120 sql queries on a page with a table present.
    Does this sound right – plugin check shows Tablepress using around 50% of the resources to load the page

    Number of PHP ticks: 60,218 calls avg.
    Memory Usage: 90.53 MB avg.
    MySQL Queries: 121 queries avg.

    Plugin Author TobiasBg

    (@tobiasbg)

    Hi,

    I’m not really sure whether 120 queries is a lot (that depends on the theme and other plugins, and what functionality you are using), but for a page with one table, TablePress should only account for 2 to 3 queries.
    You might want to check out one of the plugins that will show you the actual queries, so that you can find those that take very long.

    Depending on how big the tables are, TablePress might need some more of that PHP memory, but 90 MB in total is fine.

    For the PHP ticks: I have no comparison here, but 60,000 calls to PHP functions does not sound much for WordPress, given the many filter and action hooks that run all the time.

    Regards,
    Tobias

Viewing 13 replies - 1 through 13 (of 13 total)
  • The topic ‘resource issue’ is closed to new replies.