nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Constituent search performance very slow

Dave Henseler

I find the constituent search API runs very slowly, between 4 and 10 seconds per search (by partial address) that returns between 0 and 5 constituents. When I do a similar search using the DB view utility it goes much faster.

As the API search field only supports lookup id it seems like search has to blindly look at everything in constituent to find a match on address (or anything other than lookup id).

Can anyone confirm slow search performance? Or know any way to improve performance?

Thanks, Dave

Find more posts tagged with

Comments

Steven Cinquegrana

Hi @Dave Henseler. Yes, I believe you're correct about the manner in which searches occur which must be quite demanding of the back end and therefore slow. Just a guess.

If you search the Community for “constituent search” you'll likely come across several posts about this.

Cheers,

Steve Cinquegrana | CEO and Principal Developer | Protégé Solutions

Dave Henseler

Thanks Steve. I hadn't looked back far enough to see your post from … 2019!

I'm porting an app from BB CRM and the search API there worked perfect as you could specify exactly what field to search, fuzzy/not worked and it was fast (with the same data I'm using with RENxt).

When I use the DB view utility on RENxt it works as you would hope: it allows you to specify the field to search (e.g. address or many others) and the performance is a lot faster than the API. That means that everything necessary exists in the backend making not exposing that functionality in the API difficult to justify.