Roadmap 0.10, Performance roadmap — wave 3
PERF.42 Website: Library browse sorts every published item on a computed key and counts them again on every page; at 100x it is seconds per page
LibraryItems.php:152-157 orders by COALESCE(v.published_at, i.updated_at) DESC after the join, so LIMIT cannot help: EXPLAIN shows all 13,846 rows read through idx_browse, joined, then a filesort (64 ms) plus SELECT COUNT(*) (30 ms) plus categoryCounts (:171, 30 ms) per request; OFFSET 9600 takes 98 ms. At 1 M items the same plan is 5 to 7 s per browse page. Fix: a stored library_items.sort_at kept by LibraryItems::refresh() and on publish (the current version's published_at, else updated_at); indexes idx_browse_sort (visibility, status, sort_at, id), idx_browse_kind (visibility, status, kind, sort_at), idx_browse_cat (visibility, status, category, sort_at); ORDER BY i.sort_at DESC, i.id DESC reads 24 rows; keyset paging (?after=sort_at|id) past page 20; the count and categoryCounts cached 60 s per filter key or kept in a counts table on publish. Note: one account owns 13,844 of 13,846 items today, so the author filter plans say nothing yet about a real multi-author Library.
Community comments
No comments yet
Add detail as we go: how you would use it, files or steps that show the problem, what other programs do. The team reads every comment.
Sign in or create a free account to add a comment.