Home Analyst Portal

Slow API commit for workitem updates after 9.0.3

Marc-Andre_LafleurMarc-Andre_Lafleur Customer Adept IT Monkey ✭✭
Since I've update the portal to 9.0.3, committing updates to workitems using the API has become really slow. A task that used to take 3-5 seconds will now take 20-30 seconds. I've tried both from a javascript task and from powershell and get the same result.

Comitting a new projection is still quick using
{ "formJson":{"current": newProjection } }

When using it for an update (adding an activity, an action log, etc.) to an existing workitem, it takes 20 seconds minimum.
{ "formJson" : { "current" : { projection object with changes }, "original" : { original projection object } } }

Does anyone experience the same kind of result using 9.0.3?


  • Options
    Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    I think this may have more to do with what you are committing, than an overall worsening of the performance on that particular endpoint.  I am seeing between 20-60 miliseconds with that particular endpoint for small updates (ticket lock/re-lock).

    What are you committing that is performing worse?  A ticket?  Then the question is whether it might be a DB issue (such as updating the ECL/RECL tables) or something with that endpoint itself that has changed.
  • Options
    Marc-Andre_LafleurMarc-Andre_Lafleur Customer Adept IT Monkey ✭✭
    The reason why I thought there was something wrong with this specific API call is that even if I only change the title, it will take up to 30 seconds to commit.
    If I create a new workitem projection, make some changes and add activities, then commit take less than 2 seconds. Nothing else on my portal seems affected.
    I will take a look at my DB but it seems to me that it is related to that endpoint. Have you tried it on 9.0.3 and got different result that me?
  • Options
    Tom_HendricksTom_Hendricks Customer Super IT Monkey ✭✭✭✭✭
    Yes, I tried it on 9.0.3, that's what my timings are from.

    I agree that clearly the issue is when you are using this endpoint, but my point is that it is possible that the issue is not in the endpoint itself but rather something that it is touching in the normal course of saving.  I mention it just so that the possibility isn't missed.
Sign In or Register to comment.