Thread

I’m looking for some perspective on performance of EE’s search module.

Does anyone have a sense for how it would perform with, say, the following parameters:
Several thousand entries
3-6 searchable custom fields, totalling several-KB per entry
Average of several hundred searches per day
Meanwhile, average of several thousand hits per day on EE generated pages (maybe tens of thousands)

I’ve looked at the search module code and it doesn’t seem like a particularly efficient method (e.g. no index can be used for the custom fields being searched), but I’m wondering if that would be of practical concern with stats like the above, or of negligible concern.  E.g., if searches are completed in ~1 second and the queries don’t generate excessive server load, then in practical terms it is efficient.

I use the search module with several thousand entries and everything is in custom fields, naturally. The performance has been good if not great. It’s not as fast or sophisticated as, say, Google. But it does the job well enough and fast enough that it’s not worth my effort to use anything else.

Most broad searches of all fields take anywhere from a hair below 1 sec to a hair above. Rarely more than 1.5 sec. Narrower searches can be as quick as .2 sec. I don’t get near tens of thousands of hits per day (more like 500 to 3000), but it has never strained with heavier traffic. I haven’t done any kind of load testing, though.

And, of course, your web host has a lot to do with this in how fast its server processes your SQL queries.

EDIT: P.S. My entries are, I’m guessing, 5-8 kb on average.

Thanks for the feedback, that’s really helpful.  I’ve been debating whether it’s worth the effort to try to implement a MySQL full-text search feature in concert with EE.  Also evaluated a variety of other options, including Lucene and Sphinx.

Hopefully some more people will chime in to give a broader perspective, but I do appreciate you relating your experience.