Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[bioontology-support] Bioportal REST API for search: opportunity to optimize speed?

Ray Fergerson ray.fergerson at stanford.edu
Thu May 9 14:10:56 PDT 2013


Pieter,

 

We are now doing essentially as you suggest. We are replacing the backend
infrastructure with an RDF triple store that we expect will be both faster
and have a more uniform response time. The REST api for this system will
have "paged" calls and you will be able to specify which information about
terms you want to retrieve. This system is only partially function at the
moment but should move into beta in the coming weeks.

 

Ray

 

From: bioontology-support-bounces at lists.stanford.edu
[mailto:bioontology-support-bounces at lists.stanford.edu] On Behalf Of
Pieter Sheth-Voss
Sent: Wednesday, May 08, 2013 11:31 AM
To: support at bioontology.org
Subject: [bioontology-support] Bioportal REST API for search: opportunity
to optimize speed?

 

Hi Bioportal Support  --

 

The Bioportal REST API for search seems great.  I'd like to use it to
support autosuggest within a free text area for general patient case
descriptions.

 

I ran a test with a number of terms requesting JSON against SNOMEDCT +
RXNORM + LOINC against the Bioportal server that you host. 

 

The result quality is fine, returning good matches, and usually a good
first choice.

 

Now it's just getting response times fast enough to make a natural
interface.   

 

The response times are often great, under 200 ms.  But are also often very
slow, one second or longer.  Typically, this is is when there are more
than 100 results.  

 

For the context of autosuggest, we don't need all the items (top 50 would
be plenty).  And we don't need all the data, just the preferred text,
source vocabulary, and source concept ID.

 

I wonder if you can advise from your perspective on our prospects to get
faster search times, and where you might recommend that we focus our
attention. 

 

Options from here might be:

  (a)  Installing this on our own AWS instance in our availability zone
(network latency)

  (b)  Superficially modifying the source code to return only the first N
results (payload size)

  (c)  Replacing the backend datastore with a different database
(server-side search speed)

  (d)  More deeply modifying the search code in some form ... 

  (e)  Other

 

Thanks!

Pieter

m. 617 645 4524

 

Inline image 1

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/bioontology-support/attachments/20130509/d737fdfb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 24018 bytes
Desc: not available
URL: <http://mailman.stanford.edu/pipermail/bioontology-support/attachments/20130509/d737fdfb/attachment-0001.png>


More information about the bioontology-support mailing list