Editing Manual/Job queue (section)

== Job examples == <!--T:46-->

=== Updating links tables when a template changes === <!--T:47-->
</translate>
<translate><!--T:48--> When a template changes, MediaWiki adds a job to the job queue for each article transcluding that template.</translate> 
<translate><!--T:49--> Each job is a command to read an article, expand any templates, and update the link table accordingly.</translate> 
<translate><!--T:50--> Previously, the host articles would remain outdated until either their parser cache expires or until a user edits the article.</translate>

<translate>
=== 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>
=== Audio and video transcoding === <!--T:91-->

<!--T:92-->
When using <tvar name=1></tvar> to process local uploads of audio and video files, the job queue is used to run the potentially very slow creation of derivative transcodes at various resolutions/formats.

<!--T:93-->
These are '''not suitable''' for running on web requests -- you will need a background runner.

<!--T:94-->
It's recommended to set up separate runners for the <tvar name=1><code>webVideoTranscode</code></tvar> and <tvar name=2><code>webVideoTranscodePrioritized</code></tvar> job types if possible. These two queues process different subsets of files -- the first for high resolution HD videos, and the second for lower-resolution videos and audio files which process more quickly.