Creates massive logs in wp_postmeta, causing slow editing

  • cycas

    (@cycas)


    9 years, 9 months ago

    This plugin does create working redirects for removed pages.

    However, with logging turned on, as it is by default, it logs every 404 request to the wp_postmeta table. This can result over time on a busy site in a very large table, and since this table needs to be checked to load the ‘edit page’ interface, a wp_postmeta table that is full of logs can result in a very slow load for page editing.

    Further, if the plugin is removed, the log entries are not removed. You need to remove them by finding the ‘clear logs’ button before deleting the plugin. I don’t think this is made obvious.

    If you are dealing with a site that has used the plugin once, but where it is no longer installed, it is really hard to work out what plugin the c4p_log entries in the database relate to.

    Furthermore if you do use the built-in ‘clear logs’ functionality, it will probably cause your site to run out of memory while it clears.

    I really don’t think this plugin should be storing all its logs in wp_postmeta.

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author Kunal

    (@kunalnagar)

    9 years, 9 months ago

    Hi there – thank you for taking the time to write a review for the plugin.

    A couple of things to note:

    1. The plugin description clearly states that the plugin records all 404s. If you did not want the logging, you could have easily turned it off.
    2. If your site has so many 404s that it is causing slow editing, maybe you should try and fix your site first rather than blaming it on the plugin.
    3. I do agree that when the plugin is removed, it should do a better job at cleaning up after itself. I’ve noted this down, and I shall release a fix in the next update. Thanks for the suggestion, by the way.
    4. I would recommend that you export your logs in a CSV format and analyse what is causing the 404s on your site. You know that’s really bad for your SEO.

    Thanks again for trying out the plugin. Take some time out of your cribbing to appreciate the free & open-source stuff that people make. Provide helpful suggestions, that helps.

    Thread Starter cycas

    (@cycas)

    9 years, 9 months ago

    If I had installed the plugin, I could have disabled logging, but I didn’t install it. I didn’t even uninstall it.

    I inherited a site which had no visible signs of having had the plugin installed on it in the past, and had to work out why my client was complaining that editing was so damn slow, purely on the contents of the wp_postmeta table. I left this review, so that anyone else out there thinking wtf are these c4p_log entries and why is my wp_postmeta table 200mb will have an answer.

    Cleaning up the logs on plugin removal is a good idea, but I really do not think that wp_postmeta is the table for storing them in the first place. This is one scenario where a custom table might be justified.

    As to the 404s : 404s which result from actual broken links on the website might possibly affect SEO, but 404s resulting from the activity of bots trying to find security holes will not (there are no links to the 404s: it is literally that lots of bots hit the site looking for urls that do not exist and have never existed). Because of the industry this site is in, this happens a lot, even though it is pure brochureware and doesn’t actually have any of the functionality that the bots are hoping to break into. This really is not an unusual scenario.

    Plugin Author Kunal

    (@kunalnagar)

    9 years, 8 months ago

    Makes sense. I’ve heard about logs piling up from a few others as well.

    Tell you what – I’ll disable logging by default in the next update of the plugin. The primary goal of the plugin is to help you with the 404 pages/redirects. A small notice may be shown for users who would like to enable logging. Does that sound good?

    Making a new table for the logs sounds like a good idea as well. I’ll keep it in mind.

    For the “Site running out of memory due to Clear Logs” issue, I’ve tested it out with ~25k logs and it seems to be working fine. As for your scenario, I believe you would have turned off logging by now and do the Clear Logs during downtime (at night/weekends).

    Thanks!

    Thread Starter cycas

    (@cycas)

    9 years, 8 months ago

    Thanks, that sounds like a good plan to me.

    The log I cleared (having reinstalled the plugin to do so, since I thought using the built-in tool would be cleaner than just doing a mysql clearout) was 420k+ records. On a site with the default 1024Mb memory allowance on a cloudlinux server, the process completely maxed out the memory for several minutes, making the backend unresponsive (fortunately the frontend was cached by Cloudflare and I had backups so I was chilled about it). I think that might cause some site owners to panic, which is why I mentioned it.

    However, the process did complete successfully, and hopefully if logs are not enabled by default and in future are stored somewhere less likely to affect general site performance, then not many people will be in that position going forward.

Viewing 4 replies - 1 through 4 (of 4 total)

The topic ‘Creates massive logs in wp_postmeta, causing slow editing’ is closed to new replies.