Managing cache_form when Fivestar appears in Teaser

I'm seeing a similar issue. I have fivestar in teasers and on node detail pages - 1250 nodes total. My cache_form table is 660MB !!!

As stated in drupal_build_form()'s documentation, the form cache's entries are required for ajax-enabled forms like the Fivestar widget. The most reasonable way to avoid the issue is probably to display the scores on teasers, but not allow users to vote on teasers.

If that is not an option, maybe you could have system_cron() invoked more often (perhaps through a module like Elysia Cron), to ensure that the form_cache table is cleaned-up more frequently.

I should have known this before. I had a major crash in a server due to this issue, database got corrupted, all sites in the server went down as mysql went down and lost almost a week of information (fortunately I had a backup) so I think I'm moving the priority of this.

I've been looking on ways of solving this issue and I just noticed that the entire node object is being attached to the form, making the cache_table grow even more than needed, also is there a way to make the cached form expire soon? Even with cron running every 5 minutes, expire date is too far away and I need to get those deleted almost immediately as my table grows some GBs per day!.

I've got this too, 2GB cache_form within 10 minutes. I tried to play remove the content object from form_state, but I can't avoid to write into the cache_form table.. I'm sure, this module is not able to serve high traffic sites. The fivestar widget is an ajaxified form-based widget, so the cache_form usage is unavoidable. To permanently solve this, all the widget generation logic should be refactored, remove the from dependency. I'm close to sure, it won't happen, maybe in a new branch..

The fix was for me, to change fivestar_widget to module Rate.

I fixed this for a project I was working on a few days ago but just didn't have enough time to create a patch (sorry about that). It probably needs to be rerolled for the dev branch because I had downloaded the alpha2 version for my project, anyway, here it is.

I can confirm that this patch cuts the inclusive wall time for fivestar_field_formatter_view to about half as much as it was due to cache_set specifically. My cache rows are down to 1.2K blobs.

Ouch, yeah... Just realized on one server that ran out of disk space that fivestar being displayed on teasers on a heavily-trafficked site was causing over 1000 rows/minute to be written to cache_form, and that table size had grown past 20 GB in a few hours. I've simply removed the field from displaying on teaser listings, and that helps quite a bit.

It'd be great if there was a better way to solve this, though, or maybe a more stern warning on the project page / readme file about form cache implications.

Thanks :)

Fix is in the latest 7.x-2.x-dev

I think this fix merits a release as soon as possible. Hopefully a maintainer agrees and proceeds with a beta2 or final release.