- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
Poor API performance for certain wildcard WAPI searches
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-04-2019 07:09 AM
I'm writing a DNS provisioning workflow engine to streamline resource record approvals for CRUD operations. As part of the update and delete functionality, I have an autocomplete field that will give them a dropdown of possible existing records they are looking to update/delete as they type. Basically, until they select from the dropdown, they can't go forward (i.e. the record must exist or they can't do anything with it, which is obvious). The problem came up where a user typed in *.apps.cfdata and nothing pre-populated, even though it exists as a record in our <100k recs. After tracking down what went on on the backend, I found that the search (name~='*.apps.cfdata' or something to that effect) took upwards of 45 seconds to complete whereas the standard www.blah came back at near-realtime. Had the user waited 45 seconds, the dropdown would have appeared, but who waits that long? Is there a more-optimal way for me to do these searches that would benefit the asterisk searches without harming the normal run-of-the-mill search performance?
I'm using a Python library, but I know what it's doing under the hood when it comes to base wapi calls and I can modify as needed.
Thanks
Re: Poor API performance for certain wildcard WAPI searches
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-06-2019 03:49 AM
I've also noticed these kinds of delays when doing searches, I'm not sure if the underlying database is particularly optimised for doing searches in the way that a traditional SQL database engine works.
I haven't figure out a way to get around this yet, I have had ideas around pulling all the data into some kind of external storage that can be searched, but that means it's not dynamic and you'd need a scheduler to re-sync the data every so often. Not ideal at all. :-(
PCN (UK) Ltd
All opinions expressed are my own and not representative of PCN Inc./PCN (UK) Ltd. E&OE