Search function slow since 0.98.0

[Newcomer1989]

Description

The new search UX is really nice!

I have a rather large Trilium database. The search function used to be a little slow before, but still within a reasonable range.

Since version 0.98.0, however, it has become very slow - about five times slower compared to the previous version.

It would be great to see some optimization of the search performance.

TriliumNext Version

0.98.1

What operating system are you using?

Ubuntu

What is your setup?

Server access only

Operating System Version

Ubuntu 24.04.2 LTS

Error logs

High word count for note CgHdgKy91P2I: 187927 words - phrase matching may take time but will attempt full search
High word count for note CgHdgKy91P2I: 187927 words - phrase matching may take time but will attempt full search
Slow 200 GET /api/quick-search/repkav with 8959 bytes took 8877ms

[perfectra1n]

Ahh, yeah I should've been more aggressive with filtering out large Notes like that:

CgHdgKy91P2I: 187927 words

I loosened the size of allowed Notes in search results some, I should probably decrease it a little bit more than allowing a 187927 word Note to be searched 😂

Trilium/apps/server/src/services/search/utils/text_utils.ts

Lines 21 to 22 in f3416fa

	PERFORMANCE_WARNING_SIZE: 5 * 1024 * 1024, // 5MB - warn about potential performance impact
	PERFORMANCE_WARNING_WORDS: 100000, // 100K words - warn about word count impact

[Newcomer1989]

For testing purposes, I removed this note. It wasn’t much faster without it.

200 GET /api/notes/f8WRDnHFKgEn/blob with 4378 bytes took 3ms
204 PUT /api/options with 0 bytes took 3ms
Slow 304 GET /api/quick-search/kav with 26056 bytes took 7470ms
Slow 200 GET /api/quick-search/test with 153513 bytes took 8153ms
Slow 200 GET /api/quick-search/tariferh%C3%B6hung with 50247 bytes took 7845ms
Slow 200 GET /api/quick-search/qsks2 with 2217 bytes took 7694ms

Some additional data. If you need more information, please let me know.

DB size: 420196 KB
Table counts: notes: 2898, revisions: 586, attachments: 1554, branches: 2918, attributes: 5195, etapi_tokens: 2, blobs: 3108

sqlite3 document.db "select count(*) from notes"
> 2898

sqlite3 document.db "SELECT SUM(LENGTH(content)) FROM blobs;"
> 385135006

[perfectra1n]

What hardware are you running the server on? I have always found it interesting that the search is so much slower through the WebApp than native (takes about 1/2 or 1/3rd the time), I wonder if there's something I could do to speed that up as well. Here's my stats:

Slow 200 GET /api/quick-search/hello with 65387 bytes took 3000ms

Table counts: notes: 4544, revisions: 2103, attachments: 15352, branches: 4703, attributes: 3758, etapi_tokens: 44, blobs: 8030


SUM(LENGTH(content))
--
722056339

[Newcomer1989]

How large is your database? Three seconds for a Trilium instance that’s twice the size seems reasonable.

CPU: Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz
Cores: 16
RAM: 31Gi total, 17Gi used
Swap: 1.0Gi total, 1.0Gi used
Disk: nvme1n1 419.2G nvme0n1 419.2G
OS: Ubuntu 24.04.2 LTS
Kernel: 6.8.0-64-generic

[perfectra1n]

Mine is 755MB large :)

I think the main difference between you and myself is the CPU - this is that same search on a Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz (data is mounted via iSCSI, spinning rust):

Slow 200 GET /api/quick-search/hello with 65387 bytes took 5994ms

The 3 second search above was done on a node that has a 5800X backed by the same iSCSI spinning rust as above, so I'm guessing the CPU plays a pretty large impact here (which would make sense, given the kind of searching that it performs) 🤔

[perfectra1n]

Maybe I just create an option in settings to enable/disable fuzzy search globally for older CPUs...

[rom1dep]

Interestingly, I have a CPU that's merely better than a toast potato (3200 on cpubenchmark) pushing through spinning rust, 510MB of a database, and it's decent:

21:06:39.875 Slow 200 GET /api/quick-search/fuzzy with 58 bytes took 353ms
21:06:43.039 Slow 200 GET /api/quick-search/fu with 98378 bytes took 443ms

perhaps there's some specific kind of notes causing this? Either way, such an option is good to have!

[Newcomer1989]

I copied the same database to my local device.

It’s faster here, but still slow. I wouldn’t say it’s just the CPU.

CPU: AMD Ryzen 9 3900XT 12-Core Processor
Cores: 24
RAM: 15Gi total, 923Mi used
Swap: 4.0Gi total, 0B used
Disk: sda 388.4M sdb 4G sdc 1T
OS: Ubuntu 24.04.2 LTS
Kernel: 5.15.167.4-microsoft-standard-WSL2

High word count for note 9hgrpidBfKxv: 187927 words - phrase matching may take time but will attempt full search
High word count for note 9hgrpidBfKxv: 187927 words - phrase matching may take time but will attempt full search
Slow 200 GET /api/quick-search/qsks2 with 2217 bytes took 4330ms
High word count for note 9hgrpidBfKxv: 187927 words - phrase matching may take time but will attempt full search
High word count for note 9hgrpidBfKxv: 187927 words - phrase matching may take time but will attempt full search
Slow 200 GET /api/quick-search/qsks1 with 3057 bytes took 3949ms
High word count for note 9hgrpidBfKxv: 187927 words - phrase matching may take time but will attempt full search
High word count for note 9hgrpidBfKxv: 187927 words - phrase matching may take time but will attempt full search
Slow 200 GET /api/quick-search/test with 153828 bytes took 4681ms
High word count for note 9hgrpidBfKxv: 187927 words - phrase matching may take time but will attempt full search
High word count for note 9hgrpidBfKxv: 187927 words - phrase matching may take time but will attempt full search
Slow 200 GET /api/quick-search/kav with 26056 bytes took 4402ms

[perfectra1n]

Hmm, that's super interesting. I'm assuming the times are very similar (or perhaps the same?) with the larger note 9hgrpidBfKxv removed?