Editing Manual/Job queue (section)

=== HTML cache invalidation === <!--T:52-->

<!--T:53-->
A wider class of operations can result in invalidation of the HTML cache for a large number of pages:

<!--T:54-->
*Changing an image (all the thumbnails have to be re-rendered, and their sizes recalculated)</translate>
<translate>
<!--T:55-->
*Deleting a page (all the links to it from other pages need to change from blue to red)</translate>
<translate>
<!--T:56-->
*Creating or undeleting a page (like above, but from red to blue)</translate>
<translate>
<!--T:57-->
*Changing a template (all the pages that transclude the template need updating)
</translate>

<translate><!--T:58--> Except for template changes, these operations do not invalidate the links tables, but they do invalidate the HTML cache of all pages linking to that page, or using that image.</translate> 
<translate><!--T:59--> Invalidating the cache of a page is a short operation; it only requires updating a single database field and sending a multicast packet to clear the caches.</translate> 
<translate><!--T:60--> But if there are more than about 1000 to do, it takes a long time. By default, one job is added per '''300''' operations (see <tvar name=1></tvar>)</translate>

<translate><!--T:95--> Note, however, that even if purging the cache of a page is a short operation, reparsing a complex page that is not in the cache may be expensive, especially if a highly used template is edited and causes lots of pages to be purged in a short period of time and your wiki has lots of concurrent visitors loading a wide spread of pages.</translate> 
<translate><!--T:96--> This can be mitigated by reducing the number of pages purged in a short period of time, by reducing <tvar name=1></tvar> to a small number (20, for example) and also set <tvar name=2></tvar> for <tvar name=3><code>htmlCacheUpdate</code></tvar> to a low number (5, for example).</translate>

<translate>