We have a site with a search function that uses Search::pages($query)
under the hood. The site index has around 700 pages, everything worked nicely in K3 and it still does locally. But after an upgrade to K4, on the same live server, the search times out.
Did anyone else expericence something like this before?
My first guess was this has to do with an unpopulated UUID cache but that doesn’t seem to be the case. Any ideas what might cause this or what might have changed between Kirby versions?
Apart from the Kirby update, did you also update PHP?
Then I’d check the php.ini settings, max_execution_time in particular.
But the localhost and the server are running the same PHP version (8.2).
Well, it takes at least half a minute until the server times out. Locally, and with K3, search results came in in under a second.
For reference, we use a collection for searching which looks like this:
<?php
use Kirby\Cms\Pages;
use Kirby\Cms\Search;
return function () {
if (!get('query')) {
return new Pages();
}
$query = htmlspecialchars(get('query'));
$pages = Search::pages($query);
return $pages
->listed()
->filterBy('template', '!=', 'team')
->sortBy('searchPriority', 'asc');
};
I just checked and the setting is 30
on localhost and 180
on the live server.
Hm, ok. From which PHP version did you upgrade? Guess no version that still works with Kirby 4?
We were on PHP 8.1 before. But switching back to that version doesn’t change anything …
I do see some time improvements on PHP 8.1: results do come in after around 50 seconds. Still, that is close to a minute.
I created a test file to see, how long it takes Kirby to generate the site index:
<?php
require 'kirby/bootstrap.php';
$kirby = new Kirby();
dump($kirby->site()->index());
die();
Localhost will return a full index after max. 200ms, the live server will take 10000ms. Same content on both servers, but the live server had its media and file caches cleared after updating.
Question: Does Search::pages()
resolve all KirbyTags within content files when searching?
No, internally, this method uses the search component, which in turn just looks at the raw content data.
One thing that is not clear to me when looking at the search component git history is that cloning the collection was removed and then again added. No idea why and if that might even make any difference.
I digged a little deeper and this issue seems twofold:
- We actually had an issue with KirbyTags being resolved on search – but this was happening in our template. It caused high traffic on the server because a lot of images got pre-rendered by accident.
- Ignoring the first issue, the search on the live server takes around 50 times longer than on the local server.
Issue #1 has been fixed. #2 is still a mystery to me …
I’m still debugging this and looking into the server stats I see high CPU usage since the upgrade to Kirby 4. Is there anything in the Kirby core that can cause this besides image thumb generation?
So, it turns out the hosting provider messed things up and we ended up with an install half Kirby 3, half Kirby 4. However that could happen. Re-uploading everything solved the issue
Thanks Sonja for helping me debug this!