Open Calais / Intelligent Tagging API Performance

ben.mccullough
ben.mccullough Newcomer
in Open Calais

We recently updated our configuration of Open Calais to point to api-eit.refinitiv.com from the old api (api.thomsonreuters.com) and the performance is terrible. Average response times went from about 2 seconds to greater than 6 seconds with spikes of up to 22 seconds. Has anyone else noticed this degradation in performance?

Tagged:

Answers

  • zoya faberov
    zoya faberov ✭✭✭✭✭

    Hello @ben.mccullough,

    We have re-verified this with our DEV team, and we don’t see any issues with the response time for tagging using the new URL.

    Could you please help us further understand this:

    • Confirm if you are seeing this delay consistently
    • Provide details about the input/file type (txt, xml, pdf etc.)

    Thanks,

    -AHS

  • ben.mccullough
    ben.mccullough Newcomer

    imageThe situation has become worse - here is a graph of the last 24 hours in New Relic.
    For the last hour the average response time has been 13,900ms.

    Yesterday's average for the same hour was 1,800ms (an improvement over previous numbers).

  • zoya faberov
    zoya faberov ✭✭✭✭✭

    Hi @ben.mccullough,

    Are you able to provide the input samples/details, by attaching them here, as requested by product development team?

    This way they will be able to test same as you.

  • ben.mccullough
    ben.mccullough Newcomer

    We are using the Drupal 7 version of the OpenCalais module (https://git.drupalcode.org/project/opencalais) installed years ago and performing generally well since installation.

    We are sending data in XML/RDF format.

    Some important notes:
    1) Performance has been very inconsistent. Initially it was slow (first report above), then settled into a comfortable range (occasional spikes, but acceptable - could be content related). Around 05:00 UTC performance became terrible >40,000ms fairly consistently.

    2) Today we switched back to api.thomsonreuters.com and observed similar but less consistent behavior. Many requests <8,000ms, but then a spike of >80,000ms

    3) We have temporarily disabled the API call and plan to reinstate the service again in the morning

Categories