Expected Caching Times

[faustbrian]

I'm working on a multi-site setup that currently has 820 pages across 6 sites, so basically 136-ish pages per site. Without this package the caching times per page around 1-2 seconds but when using this package the caching times jump to anywhere between 8-14 seconds.

Various caching drivers have been tried and none of them result in any significant performance improvements, so it's not an I/O issue. I saw other issues/discussions about the performance impact of SEO packages in Statamic but should it really have a 5-8x impact per page? This makes static cache rebuilding in production rather tedious when we have to do a full rebuild because this then takes several minutes for very basic pages that don't do anything fancy.

Are there any things that can be configured to lower the impact of this package on how long static cache creation takes?

[aerni]

I'm aware of the performance issues. The root of the problem is likely the inner workings of Statamic's data augmentation, which is used extensively in this addon.

I suppose you are using half measure static caching? And then use the php please static:warm command to warm the cache? If you clear the cache and manually visit a page, does it also take between 8-14 seconds to warm that one page?

You can probably improve the static caching performance if you first run php please stache:warm before running php please static:warm. This will ensure that the stache isn't built on demand but ready to go.

One possible solution might be to provide some sort of SEO warm command that will gather all the data and cache it. Similar to stache:warm. So when the static cache is built, all data is ready to go.

[faustbrian]

We currently deploy like this and that's the setup we see the 8-14s times with. Static Caching is set to full and manually visiting a page takes the same amount of time with and without warming.

git pull origin $FORGE_SITE_BRANCH

if [[ $FORGE_QUICK_DEPLOY == 1 ]]; then
    if [[ $FORGE_DEPLOY_MESSAGE =~ "[BOT]" ]]; then
        echo "AUTO-COMMITTED ON PRODUCTION. NOTHING TO DEPLOY."
        exit 0
    fi
fi

$FORGE_COMPOSER install --no-dev --no-interaction --prefer-dist --optimize-autoloader

( flock -w 10 9 || exit 1
    echo 'Restarting FPM...'; sudo -S service $FORGE_PHP_FPM reload ) 9>/tmp/fpmlock

npm ci
npm run build

$FORGE_PHP artisan cache:clear
$FORGE_PHP artisan config:cache
$FORGE_PHP artisan route:cache

$FORGE_PHP artisan horizon:terminate

$FORGE_PHP artisan statamic:stache:warm
$FORGE_PHP artisan statamic:search:update --all
$FORGE_PHP artisan statamic:assets:generate-presets --queue
$FORGE_PHP artisan statamic:static:clear
$FORGE_PHP artisan statamic:static:warm --queue

[aerni]

This looks all good. What are your server specs? What does the load look like when building the cache? You might be able to get better results by increasing CPU and RAM.

[faustbrian]

It's running on a server with 64GB of RAM and 32 Cores. There's some other applications on it but the resources usually idle around 40-50%, so there's more than enough resources and it's not any resource starvation.

[aerni]

Ok, good to know. That's a beefy machine 😅. I'll try to make some time to investigate these performance issues some more. Do you have a test project you can share?

[faustbrian]

I'll check if I can get you access to the real repository since it's relatively large in terms of page count.