Thousands of s2m transients in WP database

I read this post:

http://www.s2member.com/forums/topic/transient-s2m-orphaned-options/

That says it’s unwise to delete any transients that look like these:

_transient_s2m_ipr_9956e1a3022e58d…
_transient_s2m_rtn_2c71b18200b7fb1…
_transient_s2m_ipn_c34f8253d048595…

But the number of these transients is getting into the thousands now and beginning to slow things down.

What can be done about this? It doesn’t seem that anything is removing them automatically.. so eventually something’s gotta give..

Please advise.

Hi Jeff.

I’ll ask Jason when transients would normally be removed, but the way I understand it, It’s something WP should do on its own eventually. Is your wp-cron working properly?

Here’s something Jason told me about transients once:

When the logs say that it’s storing data in a transient queue, it’s because there is no account associated with the user yet. Meaning, there is no way for s2Member to associate that data with a user of the site (yet). Therefore, the data is stored in a transient queue, and then reprocessed as soon as the user registers for the site and obtains a username/account for s2Member to process the data against.

You’ll usually see this message on IPN messages that are related to incoming payments (or immediate EOTs triggered due to failed initial payments).

For instance, PayPal will sometimes trigger an IPN for the initial subscription payment, before the user has returned from PayPal and registered for the site. In this case, s2Member stores the payment data and processes the IPN message during registration, where the registration subscription ID matches that of the transient IPN data.

No, this will not affect cookie and/or registration access in any way.

Are users registering without trouble to your site? The transient should be removed once he registers, if I understnad that correctly.

Thanks for the reply. Yes everything (cron, user registration, etc.) is working perfectly fine with no issues whatsoever.

The information you posted is interesting, but does not resolve anything. What I need is a actionable way to remove the 4000+ (and growing) transients from my database table. They are consuming an ever-increasing amount of space that will eventually cause serious problems.

Please let me know exactly how to remove the transients from the options table, or other solution for resolving this issue.

Thank you for your help.

Jeff, I’m waiting for Jason to get back online and see the message I left him, but in case he needs it, could you send the site’s info? This is not a problem that is normal, it seems particular to your installation, so he may want to take a closer look at it. s2Member® » Private Contact Form

In the meantime, could you try the tests in this article? Knowledge Base » Common Troubleshooting Tips

Particularly the server tests and the plugin conflicts, although I’m not sure if the solution in this particular case would be obvious immediately after deactivating a plugin if it’s causing the problem, or if it’d require some time.

I’ll try to do as much of the troubleshooting as I can and as time allows.

I just hope that s2m isn’t using transients as long-term storage. At some point the transients should be fine to delete, I just need to know when that is.. for example, all of the users have registered and successfully created accounts, so why are the transients needed after that point? From the WP Codex:

WordPress Transients API, which offers a simple and standardized way of storing cached data in the database temporarily by giving it a custom name and a timeframe after which it will expire and be deleted.

Based on this, at some point it should be fine to delete all of the s2m transients.. ultimately they are meant to be temporary, correct?

Right, if the user already registered, the transient would not be needed there. That’s why I suggested doing the troubleshooting tips. It is possible that a plugin is causing that to not be working correctly.

Thanks for the information, Cristián. I went ahead and deleted all 4,310 of the s2m transients and everything seems to continue to work great. I’ll report back if anything weird happens or if something breaks.

Note to anyone reading this thinking about deleting their s2m transients: make a backup of your options table and entire database before deleting anything, just in case.

Thanks again for the help.

Thanks for the heads up on this thread.

It is generally NOT harmful to delete s2Member transients, because these contain only temporary data that is not absolutely necessary to the functionality of s2Member over the long term. So what you did is fine. However, please note that after deleting s2Member’s transients, you’ve also reset your IP Restrictions for s2Member, as s2Member uses transient details to track customer behavior over a 30 day period (30 days is the default configuration). See: Dashboard -› s2Member® -› Restriction Options -› Unique IP Access Restrictions

Each transient is associated with an expiration date in the DB, and s2Member will automatically purge these from your DB over time via WP Cron. Having thousands of transients would NOT be uncommon on a site where there are MANY users. I’m not aware of any performance impact with this either. The use of transients would need to reach the 100’s of thousands (or more than a million in many cases) before most sites would even begin to feel a strain of any kind with this. WordPress does not autoload transients, they are just in the DB for reference as needed, and take up very little space.

_transient_s2m_ipr_9956e1a3022e58d… (tracks customer IP addresses)
_transient_s2m_rtn_2c71b18200b7fb1… (helps to prevent duplicate return-page handling)
_transient_s2m_ipn_c34f8253d048595… (helps to prevent duplicate IPN processing)

NOTE: WordPress does NOT automatically delete transients over the long term. s2Member handles this via WP Cron. It is a common assumption that WordPress will purge transients from your DB via WP Cron using a default installation of WordPress. That is NOT the case (not with a default WordPress installation). A plugin must provide this functionality, and s2Member handles transient cleanups via WP Cron for you.

Each transient in the DB has two rows.

_transient_s2m_.... (the data being stored)
_transient_timeout_s2m_... (the timeout/expiration value)

Hi Jason,

Thank you for the infos! Good to know I didn’t break anything by deleting 1000’s of s2m transients. I didn’t think it would be a big deal to delete them, but this thread led me to think otherwise: http://www.s2member.com/forums/topic/transient-s2m-orphaned-options/

..there, Bruce says this:

It would be unwise to delete transient data of any kind (especially s2Member’s IPN transient data), as it is important for the time that it is there, and when it’s not needed WordPress will delete the data automatically.

Further, when searching for answers or clues to this issue, that Bruce thread is the only thing available. Hence this new post to clarify. Hopefully it helps others in the same situation.