Performance

Caches

As stated, the Kirby Kart plugin uses several caches to keep things fast. When changes occur via the Kirby's PHP methods or the Panel, they are automatically flushed or specific entries removed.

If you change products, stock or orders via external means like FTP, you must manually remove the respective caches. But do not remove the crypto and router caches unless you know what you are doing. If you skipped setting their SALT via .env you might end up breaking existing URLs with signatures.

Bottleneck: UUIDs

By default, Kirby creates a single cache file for each UUID to ID mapping. This file resolves page://6g8adtven6nwaicx into the product/dragonfly-lollipop, users, or images. This seems harmless at first, but within the Kirby Kart, many references are stored.

The primary concern is how many will be resolved in a single HTTP request. Many of those references must be resolved when repopulating a cache or rendering a list of products. Imagine simultaneously loading all products, orders, and stocks and determining their relationship.

I deeply explored what causes the bottleneck here using SPX Profiling. You should be grand if you have fewer than 200 products and users within Kirby. At about 500 entries, you will notice a performance drop to about 200ms per request. Up to roughly 2000 entries, the loaded files are "hot" and in server RAM, quickly available – below 500ms. Past 2000 entries, you can expect a decrease of 1 second per additional 2000 entries loaded in a single request. Roughly half of this is caused by Kirby creating more PHP objects, and the UUID cache files cause the other half, and the content files no longer fit into the granted number of "hot" files your server gives you. That massively slows down the content loading and UUID resolution that ships with Kirby's core.

Remember that the Kirby Kart plugin regularly loads everything related to products, stock, and orders in a single request when caches are flushed and repopulated. This will happen, and it will be noticeable!

TL;DR;

Beyond 200 products or users, I advise using a specialised UUID cache driver to handle large numbers of lookups in a single request.

I have created a separate, performance-focused plugin called Turbo that, among other things, provides this. The models of the Kirby Kart plugin have built-in support for Turbo if installed with Composer.

However, the UUID cache driver alone would make it worthwhile, even if you do not use Turbo's mostly Redis-based functionality. For that reason, the Kirby Kart plugin includes the same UUID cache driver.

<?php
return [
    // ⚠️ the UUID cache-driver you need to set yourself!
    'cache' => ['uuid' => ['type' => 'kart-uuid']], // exec() + sed
    
    // ... other options
];

Are you curious about what that UUID cache driver does differently? It stores all UUID-ID mappings in a single file. Making it safe across different PHP workers needed an out-of-the-box approach. exec() and sed must be available for it to work.

Other options

You could opt not to create user accounts automatically, not store orders within Kirby, or not use stock management to reduce the number of relationships. But using Turbo might be easier.