Precompilation of pages - what's the purpose?

docs.sitefinity.com/for-developers-precompilation-of-pages-in-sitefinity

It's clearly targetted at the production environment. fine.
Speeds up pages and supposedly gets rid of the terrible warm up phase. great! 

What the documentation doesn't seem to state very clearly is whether or not you run this once and off you go.
I get that the compiled pages can be invalidated through changes to the pages and templates, but does that mean that you then have to rerun the tool to get those pages compiled again? 

Also, what about pages where you have user comments? Does that invalidate the page?

If so, what's the best strategy for this? Schedule a job to run this tool once a day? 

Considering resources and the time it takes to perform the action... does the tool do this incrementally or will it start from scratch on each run? 

I have just asked much the same question to support an hour ago.

I am assuming that if you have a site that has regular page updates then rerunning the precompile tool each day will be good.

That cached pages by-pass the pre compiled templates. So it only affects performance when the page is not in the cache.

I am looking at pushing the newly precompiled dll to the live site via a automated job.

But a thing to consider is that every time you push a new dll to the bin then the site reloads\re initiates. To avoid this you can set <compilation> elements attribute optimiseCompilation=true. This avoids that auto reload by asp.net.

I'll post my findings as I go along.

Thanks Darrin, I'd be interested to hear more. 

@Darrin - have you gotten any wiser with this process? 

We've unfortunately gotten a report from Google a short while ago listing thousands of 301/302 redirects based on the warm up Status page which is more than likely happening because when the crawler activates the site is not actively being used by end users and Google might be firing up X number of requests per second getting these responses instead of the actual page that has already been indexed. Frustrating. 

So this has become a little obsolete for me as I push everything to the Feather MVC

Your 302 could be resolved by a different means.

One thing you should do for your site is to set the "Idle Time Out" value on the app pool to zero. This will stop IIS unloading your site after 20 minutes of no requests. (This is by design)

Another option is to also set up ping requests via a monitoring tool to access your most popular pages. This first keeps the site always up and in memory avoiding the point above and keeps that page in cache.

Another option is to increase your default page cache time. The default is 2 minutes, Jump it to 10.

There is also an option that I recommend to reduce the number of versions of that page that get stored in the cache.

www.sitefinity-stuff.com/.../vary-by-custom

The above will mean the site only goes into "Init" mode when you deploy something to the bin directory or update the web.config. (These are triggers to IIS to restart the app)  And you will be in control of that.

@Darrin - Do you have any suggestions on tools to use to ping the site? 

In the past I have used https://www.pingdom.com/

Currently I am using Azure Application Insights as I host my sites on the Azure platform.

Thanks Darrin, one of the guys from Progress mentioned cURL and Task Scheduler which I've done and it seems to be working so far.