I’m currently in the process of building a client website that features around 800 pieces of content in one section.
After trying to manage all of them in one folder and Kirby taking more than 10 seconds to just list them all in the panel, I abandoned this approach in favor of year-based folders, containing 50-60 pieces each. The panel still takes multiple seconds just to list them. When trying to build a public view and iterating through the articles by year, it takes a comparable amount of time.
The test system is a local VirtualBox instance running FreeBSD 12.3, PHP 8.2 and caching is enabled in
config.php. It uses 2 GB of RAM, one CPU core and SSD storage, just as the production server will. The WordPress site it is supposed to replace runs very fast on this setup (including the full MySQL setup) with caching enabled, whereas Kirby usually chokes.
Since I’m new to Kirby, I’m probably overlooking something. Enabling and disabling caching has no noticeable effect, so there must be something amiss or I’m doing something wrong.
Even worse is recursive iteration. The content pieces partially contain audio files that are supposed to become an iTunes-friendly RSS podcast feed — automatically generated. When I do this and iterate over the yearly folders like this
foreach (page('/articles/archive')->children()->listed()->sortBy('title', 'desc') as $year) : foreach ($year->children()->listed()->sortBy('date', 'desc') as $article) : if ($audio = $article->audiofile()->toFile()) :
it takes upwards of 20 seconds to process all entries at full CPU load, which renders this approach essentially useless.
Is this a fundamental limitation of Kirby or am I just doing things very inefficiently?
The content will change only once a week on average. Is there a viable caching strategy to serve most of them pre-rendered, including the RSS feed?