How to Warm-Up cache after deployment?

miloshavlicek

Hi, is there any way to warm up cache of a Nette application (I mean all templates, configuration, robot loader etc.) via shell after new version deployed?

GEpic

We are using symfony\console for that purposes:

Project deployment (to production server)
Database migrations (updates)
Cache invalidation
Assets minification and deployment

Last edited by GEpic (2016-07-23 14:29)

grogy

@GEpic ok I agree it is good practice.. but it is not cache warm-up, is it?

GEpic

grogy wrote:

@GEpic ok I agree it is good practice.. but it is not cache warm-up, is it?

We are not using it in this way, but you can achieve it with this solution too. At the moment I dont work at project of size, which need to warm up cache… honestly, I'm doing everything to circumvent it. But I know that there are situations that you can't load every request. But, we are talking about cache in general, it's off… sorry.

Last edited by GEpic (2016-07-23 16:15)

ZZromanZZ

Can we warm up caches before deploy via CLI ?

I assume following scenario:

create application build in some specific_folder
run in shell: $ php specific_folder/www/index.php SomeDeployPresenter:default

I assume RobotLoader a DI container build caches automatically when application via CLI is executed.

Warmup Latte and all caches you need in eg. presenter SomeDeployPresenter and action default:

$latte = $this->getTemplateFactory()->createTemplate()->getLatte();

foreach (\Nette\Utils\Finder::findFiles("*.latte")->from(APP_DIR . "/..") as $file) {
    $fileName = $file->getRealPath();

    try {
        $latte->warmupCache($fileName);
    } catch (\Latte\CompileException $e) {
        \Tracy\Debugger::log($e);
    }
}

execute deploy atomically by switching symlink

Can I assume that created (RobotLoader, DI and Latte) caches will be properly used and not built again when first request via web interface will be handled ?

David Matějka

@ZZromanZZ it will probably work for a latte and robot loader.

But it won't work for a DI container because there is a separate container for a CLI a non-CLI. So you have to execute a “real” http request.

If you are using php-fpm, you can easily connect (e.g. with crunch/fastcgi package) to a php-fpm server and execute a request with new DOCUMENT_ROOT and SCRIPT_FILENAME parameters