I tried to figure out where Kirby would cache data for the panel to speed it up.
Does Kirby this in the site/cache folder, too?
I have a setup where only the content and the account folder are persisted over a new deployment.
In this setup, I realized the Panel will need a lot of time for opening some pages in the panel after a new deployment. That is why I try to figure out where the Panel caches its data.
Thank you for any help or links to the documentation/guides/references (I only found information about the normal cache) where I can find information about the panel caching.
The Panel doesn’t cache its content across requests. The delay could happen from the media thumbnails (stored in the /media folder) that might have to be regenerated after your deployment.
What I am wondering: You deploy the content folder, so I think content editing is happening on the other instance, but still have an accessible Panel on the receiving instance?
The content editing is happening on this instance. And this instance is only accessible from an internal network. The Production environment gets the same content but has no panel to access. So working in the panel is only possible from inside the internal network.
So back to the Question:
In the normal case, the panel would open the requested site and starts generating the missing thumbnails for the opened page in the backend? Does the panel only generate the ones that should have displayed, or every thumbnail for every file in that page-folder?
The pages where this slow performance happens in most cases don’t really have much files to display, but they are the main node for a large collection of articles further down the page/folder tree (And the collection of articles aren’t in the direct layer below, they are further down).
I am wondering that opening this page is much faster after the first visit.
Ok, then I seem to misunderstand something. You mentioned the deploy, but deploying the internal instance to somewhere else shouldn’t change anything about the internal instance. Is it speedy before but then slow after?
It will generated thumbnails needed for what’s displayed in the Panel, but only that.
If your blueprints are referencing performance-heavy collections (e.g. the site index) this can indeed slow down the Panel.
You mentioned the deploy, but deploying the internal instance to somewhere else shouldn’t change anything about the internal instance
I dont deploy the internal Instance to the Production instance. These are different deploys (which share the same code-base, from a git tag, ofc) and just the content folder from the internal instance is put into place on the production instance.
Is it speedy before but then slow after?
The internal instance is speedy before an update and slow after, yes
If your blueprints are referencing performance-heavy collections (e.g. the site index) this can indeed slow down the Panel.
Yeah, i thought about that. But that does not explain why it becomes speedy when opening pages that already been opened before
But something seems to happen also to the internal instance during the deploy. Otherwise it wouldn’t suddenly behave differently. So that’s what I am trying to understand, what changes to the internal instance.
That does sound a lot like the Panel thumbnails are being regenerated and that’s why the first request takes a lot longer than subsequent requests where those images already exist then.
That does sound a lot like the Panel thumbnails are being regenerated and that’s why the first request takes a lot longer than subsequent requests where those images already exist then.
Thats weird, I looked into the configuration and what you say about the media folder I tried to overcome a few weeks ago by also persisting the media folder. But unfortunately that does not solved the problem either.
(So the persisted folder over a new deploy are: media, content and accounts. Sorry that I did not mentioned that in my first post)
Are there any other guesses, what might happen in my scenario?
I still really don’t get what’s happening when you say deploy. You said the internal instance is the one worked on and that gets deployed to production. But something must also change to the internal instance, otherwise there wouldn’t be this difference between before and after deploy.
In general, persisting media folder can be tricky as the hashes used for the thumbnail path take the full root of the file into account - and that’s usually different between two setups. So you might want to set the 'content.salt' option to something persistent between both setups. But then again, usually that’s an issue for the instance deployed to, not the one deployed from.
A salt is set equally for both, the internal and the production instance.
A deploy in my wording is the point after I made changes to the code implementation itself (changed blueprints, templates, snippets, plugins, etc.) and then publish them from my local environment to the internal instance and the production instance.
That is done by creating an image with the updated code-base and deploying this image to pods in a kubernetes cluster. In this process, a complete new pod is created, so all not mounted folders are cleared (like the cache for example)
The persisted folder are then mounted into the pods, BUT the mounted folders are not the same for internal and production. Only the content can be synchronized from internal to production, but the media folder is not shared in any way.
Our problem should focus on the internal instance, because the production environment cant affect anything here. (Thats why I didn’t mentioned the production server in the first place at all)
Ok, but then I am lost for ideas right now. You are basically saying that nothing changes about the internal instance, yet the internal instance is suddenly slower right after a deploy. I don’t have a clue why that would be, if /media and /site/cache remain untouched for the internal instance.
I’m sorry for not being much of a better help. I really don’t get how the pod is part of the setup deployed from and not the setup deployed to. I’d still have a close eye on what’s happening to the media folder, if it gets wiped, if the thumbs afterwards have a different hash etc. – to me it sounds a lot like the Panel thumbnails would be the source of that delay for the first time loading afterwards.