Answers.Body: <p>The <code>{% cache %}</code>, by default will cache it's contents on a <em>per URL</em> and <em>per locale</em> basis.</p>
  
  <p>A lot of times when we see the behavior you're seeing, that's not the desired behavior and you should be using the <a href="http://buildwithcraft.com/docs/templating/cache#globally">{% cache globally %}</a> parameter, where Craft stores the cached segment only on a per locale basis and <em>drastically</em> reduces the number of rows in the database table.</p>
  
  <p>I'd inspect everywhere you're using the tag and if it makes sense to use <code>globally</code> parameter, swap to that.</p>
  
  <p>You can then clear the contents of your template cache tables (under Settings->Tools->Clear Caches Tool) and the database tables shouldn't grow anywhere near as large, letting the delete stale template caches task run faster.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-08-22T17:39:24.443Z
Answers.Text: Awesome thanks Brad!
Answers.UserDisplayName: Darren
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-08-21T15:52:17.977Z
Answers.LastActivityDate: 2014-08-21T15:52:17.977Z
Answers.UserDisplayName: Brad Bell
Body: <p>Is it common to have a (near)constantly running 'Deleting stale template caches' task ongoing? I commonly log in to see a task still pending several hours after the last change to the site was made, looking in the database the task usually has 50000+ 'steps'. Each step runs reasonably quickly (although it sometimes hangs) but the process appears to be taking up quite a lot of disk IO according to newrelic and clearly some pages are not getting their cache cleared for quite some time...</p>
  
  <p>What could cause this and it it solvable?</p>
  
  <p>If it's any help I have a reasonably large dynamic menu that i've put in 'cache' tags around and also have one channel with >1200 entries in it and the site is in 5 languages (although the channel with 1200 entries isn't localised) so this isn't a tiny site, performance still seems sluggish at times however.</p>
  
Tags: <cache><performance><tasks>
Title: Long 'Deleting stale template caches'
ThreadText: # Long 'Deleting stale template caches'
  
  (Asked by: username_0 on 2014-08-21)
  
  Is it common to have a (near)constantly running 'Deleting stale template caches' task ongoing? I commonly log in to see a task still pending several hours after the last change to the site was made, looking in the database the task usually has 50000+ 'steps'. Each step runs reasonably quickly (although it sometimes hangs) but the process appears to be taking up quite a lot of disk IO according to newrelic and clearly some pages are not getting their cache cleared for quite some time...
  
  What could cause this and it it solvable?
  
  If it's any help I have a reasonably large dynamic menu that i've put in 'cache' tags around and also have one channel with >1200 entries in it and the site is in 5 languages (although the channel with 1200 entries isn't localised) so this isn't a tiny site, performance still seems sluggish at times however.
  
  **Tags:** cache, performance, tasks
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2014-08-21. Score: 8 | Accepted answer
  
  The `{% cache %}`, by default will cache it's contents on a *per URL* and *per locale* basis.
  
  A lot of times when we see the behavior you're seeing, that's not the desired behavior and you should be using the [{% cache globally %}](http://buildwithcraft.com/docs/templating/cache#globally) parameter, where Craft stores the cached segment only on a per locale basis and *drastically* reduces the number of rows in the database table.
  
  I'd inspect everywhere you're using the tag and if it makes sense to use `globally` parameter, swap to that.
  
  You can then clear the contents of your template cache tables (under Settings->Tools->Clear Caches Tool) and the database tables shouldn't grow anywhere near as large, letting the delete stale template caches task run faster.
  
  > **Comments:**
  > **username_0**: Awesome thanks username_1!  
  
  ---
  
  