1.6 KiB
Performance notes
The ?seo= article filter
GET /v1/article/ assesses the SEO status of articles in memory, because the status depends on the body, the site template and the authors. Every request assesses every visible article once, to fill counts.suggestions, and ?seo= reuses that assessment to filter before paging. The cost therefore grows with the number of articles, not with the page size.
Measured by TestSeoFilterPerformance in test/seo_filter_performance_test.go (skipped with -short): 5,000 articles of about 5 KB each in one site, on a SQLite file in a temporary directory, every article with suggestions, ?seo=suggestions&size=25, slowest of 3 runs:
| Version | Time |
|---|---|
counts.suggestions added, assessment done twice |
about 430 ms |
| assessment shared between the counts and the filter | about 270 ms |
The target is 300 ms for 5,000 articles. The test also measures the default list (GET /v1/article/ with no ?seo=), which pays the same assessment for counts.suggestions. Latest run on the development machine, slowest of 3 runs:
| Request | Time |
|---|---|
?seo=suggestions&size=25 |
315 to 338 ms |
default page, no ?seo= |
307 to 329 ms |
Both are slightly above the 300 ms target on this machine (they were about 270 ms in the earlier measurement), so the target is logged by the test but not enforced; no cache or index was added. Re-run the test with go test -tags nofrontend ./test/... -run TestSeoFilterPerformance -v -count=1 after a change to the assessment rules or the article repository. The time depends on the machine; the test only fails above 500 ms.