3 ms·

Lesson N: Use a system that doesn't require you to manually remove cache files. Seriously.

by tdavis 18y ago

patio11 18y ago
So being that this is Rails there are a couple of ways I could have done this (assuming, again, that I cached): 1) Cache the page in memcached, which would give me access to an easy time-based expiry syntax. 2) Page cache. Instead of cleaning the cache with a one-line cron script, write a 10 line cache sweeper. Then, install a plugin to periodically execute the sweeper... or execute it with a cron script. 3) Page cache. Delete with a cronjob. Why I didn't do #1: Memcached is overkill for my needs, and keeping another process running on the VPS just gobbles its 256MB of RAM even faster, while giving me another potential security/uptime headache. Why I didn't do #2: Doesn't eliminate the dependency on cron, it just moves the actual delete operation from a single line in the crontab to more complicated Sweeper logic in the app. That is logic I'd then have to actually maintain and whatnot. (And doing #2 wouldn't have helped me if I had executed the Sweeper job as the same user I executed rm -rf as, because it would similarly have been unable to remove the file.) I might be careless but I don't make choices totally at random. ;)
- henning 18y ago
  "keeping another process running on the VPS just gobbles its 256MB of RAM even faster" Why not upgrade? On Slicehost, going from 256 to 512 MB is only $20 extra. If you're running a business on it, I think that's a pretty reasonable expense, especially if it can save you even a little time (within reason).
- tdavis 18y ago
  I never said you made it at random, just that even if it were the best option it was still a poor one. From the options you laid out, it appears none of them were particularly suited to your situation. If it were me, upon realizing that, I would have just waited to see if caching were really necessary before instituting a cron hack.
subwindow 18y ago
It doesn't: http://api.rubyonrails.org/classes/ActionController/Caching/Pages.html#M000294 http://api.rubyonrails.org/classes/ActionController/Caching/... Removing them with a cron task is usually the worst way to solve this problem. Using the expire_page method is the correct solution when the updates are being done as a result of a user's action (updating/deleting/creating a record). The problem here was that they weren't being done by a user, but automatically by the system.

Lesson N: Use a system that doesn't require you to manually remove cache files. Seriously.

by tdavis 18y ago

Lesson N: Use a system that doesn't require you to manually remove cache files. Seriously.

So being that this is Rails there are a couple of ways I could have done this (assuming, again, that I cached): 1) Cache the page in memcached, which would give me access to an easy time-based expiry syntax. 2) Page cache. Instead of cleaning the cache with a one-line cron script, write a 10 line cache sweeper. Then, install a plugin to periodically execute the sweeper... or execute it with a cron script. 3) Page cache. Delete with a cronjob. Why I didn't do #1: Memcached is overkill for my needs, and keeping another process running on the VPS just gobbles its 256MB of RAM even faster, while giving me another potential security/uptime headache. Why I didn't do #2: Doesn't eliminate the dependency on cron, it just moves the actual delete operation from a single line in the crontab to more complicated Sweeper logic in the app. That is logic I'd then have to actually maintain and whatnot. (And doing #2 wouldn't have helped me if I had executed the Sweeper job as the same user I executed rm -rf as, because it would similarly have been unable to remove the file.) I might be careless but I don't make choices totally at random. ;)

henning 18y ago
"keeping another process running on the VPS just gobbles its 256MB of RAM even faster" Why not upgrade? On Slicehost, going from 256 to 512 MB is only $20 extra. If you're running a business on it, I think that's a pretty reasonable expense, especially if it can save you even a little time (within reason).
tdavis 18y ago
I never said you made it at random, just that even if it were the best option it was still a poor one. From the options you laid out, it appears none of them were particularly suited to your situation. If it were me, upon realizing that, I would have just waited to see if caching were really necessary before instituting a cron hack.

subwindow 18y ago

It doesn't: http://api.rubyonrails.org/classes/ActionController/Caching/Pages.html#M000294 http://api.rubyonrails.org/classes/ActionController/Caching/... Removing them with a cron task is usually the worst way to solve this problem. Using the expire_page method is the correct solution when the updates are being done as a result of a user's action (updating/deleting/creating a record). The problem here was that they weren't being done by a user, but automatically by the system.