Using gzdeflate on serialized objects
gzdeflate( igbinary_serialize ( $object )) seems to be extremely slow on large objects like the dashboard feeds. We probably shouldn’t do it.
Use on sites with shared hosting
On a couple of shared-hosting sites (low-end GoDaddy and low-end Greengeeks) we’ve seen some SQLite timeouts. From the statistics display, it looks like there are some extreme outliers in the times taken for various operations (lookup, save, delete). An extreme outlier is an operation that takes hundreds of milliseconds, where most operations take hundreds of microseconds.
To work around this, the latest version of the plugin changed the default timeout from 0.5sec to 5sec.
Use on a FreeBSD site
Something’s wrong on a site hosted on nearlyfreespeech.net. (They give each site its own FreeBSD jail.) Each SQLlite operation (lookup, save, etc) seems to take about 5 milliseconds. That’s obviously too long for the plugin to be useful.
Hammer on a product catalog page
I tested on an otherwise idle WooCommerce / Bookshop staging site with 1,350 products. A benchmark of product catalog page 75 out of 76 showed this number of pageviews per second, higher is better.
- 13.2 with no persistent object cache.
- 18.0 with this SQLite Object Cache (36% more than no cache).
- 15.0 with the Redis Object Cache running on localhost (25% more than no cache).
- 11.3 with the Redis Object Cache running on a dedicated machine (14% less than no cache).
Benchmarking work is ongoing. If you run benchmarks please post the results in the support forum.
It’s surprising that using redis on its own dedicated machine slows things down rather than speeding them up. It’s possible I’m not measuring things correctly. And this is surely a distorted test workload. Again, benchmarking work is ongoing.
If you have benchmark results, or advice on better tests, please share them in a comment here or on the plugin’s support forum.