Support Forum

@Mr Papa - thank you for replying. You are correct, it is a post failure message. There are 2 entries per failure, with the naming scheme of _transient_timeout_{ip}post and _transient_{ip}post.

wordpress handling of transients is far from optimal, but they will get remove fairly quickly - as you notice by the small number of actual records...  1991 entries in the options table is actually quite small...  I have some sites with tens of thousands and no performance hit...

When the server was going down and I noticed the huge amount of cpu usage by mysql, I ran show full processlist quite a few times to see what exactly was causing it. When I did, each time I think I saw 6 - 12 of those record being simultaneously inserted. I don't have a db dump from the day of the actual server outtages unfortunately, but I do have one from the day before they started. The bulk of the records in the table are these entries,  and from then until I locked the forums there were roughly 30k entries added and deleted to the wp_options table. Keep in mind the whole server was down for hours and hours during this time period. While some of those inserts may have been due to other actions based on what I was witnessing it's a safe bet most were from those failed captcha attempts. In comparison, the forums were locked to new posts on June 20th, and since then there have been only 56k inserts, or roughly 1.4k inserts per day. That is a huge difference.

this one looks like a post failure message…  which is needed for when the page is reloaded to know the reason for failure so a status message can be displayed…

Is there a reason this couldn't be handled with a session variable? Or do the posting via ajax, and return the error directly instead of having to reload the page and re-query for the error? Can you think of any other suggestions to alleviate the load this is causing?

Yellow Swordfish said
30k of transients? Or 30k of those very specific transients? WordPress creates huge numbers of transient records and leaves them forever lying around. It is just about he most awful development they ever did. I regularly clean then out. So it is an important distinction.

IF you are genuinely referring to huge numbers of the SP post failure transients all related to the captcha then that suggests to me that either there are a very large number of illiterate users or - and perhaps this is more likely - the captcha plugin is not working correctly. And if it is the latter then surely that is the most important task to address? Is it not?

In 1 day the auto increment went up by 30k entries, whereas with the forum locked it went up by 1.4k per day for the next 38 days. Since they are transient and get deleted, no, I cannot say with 100% certainty that is what they were. However, prior to locking the forums and keeping a continuous eye on the mysql queries that were running, those inserts were pretty much all I saw, and I saw them in excess. Locking the forums to new posts immediately resolved the performance issue, and this is on a server with ~160 sites at the time, the bulk of which are Wordpress.

IF you are genuinely referring to huge numbers of the SP post failure transients all related to the captcha then that suggests to me that either there are a very large number of illiterate users or – and perhaps this is more likely – the captcha plugin is not working correctly.

Or, even more likely: bots. Looking through the entries the user names were things like "spain jersey", "WOLFSBURG JERSEY HOME", "hermes bag", "iraq jersey", etc... in other words, the captcha is doing exactly what it is supposed to be doing, which is blocking non-human traffic. However, once the bot traffic hits a certain threshold posting all of those failed captcha to the database causes an issue. Wasting database resources to tell a bot that they entered in an incorrect captcha is very inefficient. With normal captchas on Wordpress comments, for instance, I believe the norm is to check the captcha first, before processing anything else, and if failed raise a Wordpress error, thus halting execution of the script, not performing any more mysql queries, and saving on resource usage.

Which brings me back to the question... how do I fix this?

Thanks.

if we simply stated post refused because wrong captcha with a page reload, the post content would be lost and have to be retyped over

Is there a way to check the captcha via ajax? This would de-necessitate the need to leave the page to check it, thus saving the content, and should minimize the resources used in blocking bots.

this is odd as I still dont understand how that is killing a dedicated machine

It's possible there was something else going on with the server as well, but I can only go based on what my investigation showed, which I described above. Also, yes, this is a dedicated machine for my client, but he has 160 other clients on there, so this was not the only site by a longshot. Also, it's possible that this was just due to a particularly nasty wave of bots during that time period. The forum is not new, and appears to have been running fine for quite some time. However, the unfortunate thing is that to test that theory requires putting the server at risk of hours of downtime again, which is not something we really want to do to be honest.

I have been thinking about this more. I have not implemented the above solution yet, but thank you for that. My guess is that those entries are symptoms of the massive amount of bots trying to post, and that it is the overall processing on each attempt that was causing the load and not the entries themselves. Perhaps I should have mentioned before that due to the nature of the forum the client feels it is important to allow people to post anonymously, without needing to register, so that captcha is the only thing stopping the bots, and it is only stopping the posts from actually going through, not the processing needed on each attempt.

My thought process is that odds are the bots are most likely not visiting the forum before attempting each post, and that the captcha is failing because it is empty. Would the error be the same for an empty captcha as an incorrect one? If so, is there a way to simply halt all execution if the captcha is not included with the post? Would it be in the same file, simple-press/forum/library/sp-post.php ?

My second thought was including a randomly generated hash in a hidden form field on the post form, one that includes the timestamp in it, and look for and decrypt that field before doing anything else. If the field is missing, invalid, or more than 1 hour old, assume that the post is from a bot, and again, just kill the page.

Any thoughts on either of those methods, or their impact?