Join 34,000+ subscribers and receive articles from our
blog about software quality, testing, QA and security.

API performance


#1

Hi,

we currently have a test version of TestRail 5.3.0.3603 (cloud) to see if it fits our needs. Today I was checking the API to generate a few custom reports, and I experienced some pretty long delays.

For example a simple query to ‘get_milestones’ with a projectID takes between 580ms and 720ms (six milestones). A more complex query fetching all plans for a milestone (around 12 plans), and for each plan all runs (so 12 x ‘get_plan’) takes between 8200ms and 9400ms!

So I’m wondering if the free (cloud based) test version has some kind of limitation on the API, or if these numbers would also to be expected in the paid version (server based, no cloud).

Or is there anything that could go wrong with those basic queries? I’m using PHP for the requests.

Thanks in advance.

EDIT: almost forgot: Using the TestRail in Mozilla/Chrome installation works flawless without any unusual delays even when viewing all reports.


#2

Hi Amka,

Thanks for your posting. Can you check if you use the keep-alive option for subsequent API requests? It’s normal that the first API request is a bit slower due to the TCP and SSL hand-shake and this can add a few hundred milliseconds. If you re-use the TCP connection for subsequent API requests (keep-alive), it’s faster starting with the second request. Browser use keep-alive by default and that’s why you use a better performance/lower latency with your browser compared to the API.

I hope this helps!

Cheers,
Tobias


#3

Hi,

thanks for the hint. To be honest, I just used the testrail.php from http://docs.gurock.com/testrail-api2/bindings-php, but didn’t really took a closer look at it.

cURL has keep-alive actived by default as far as I know, but after checking the testrail.php I saw, that the connection is closed after each request.

So I just rewrote my testcode and the overall request time is now down to ~4300ms from the mentioned 8200 - 9400ms. Which in details comes down to:

#01 = 0.702 s
#02 = 0.375 s
#03 = 0.281 s
#04 = 0.280 s
#05 = 0.281 s
#06 = 0.281 s
#07 = 0.281 s
#08 = 0.281 s
#09 = 0.265 s
#10 = 0.405 s
#11 = 0.281 s
#12 = 0.265 s
#13 = 0.281 s

This might be a little faster on a local TestRail installation, but I’m not 100% sure and I can’t test it right now.
Anyway, thanks a lot for your quick reply :slight_smile:


#4

Hi Amka,

Thanks for your reply and great to hear that it’s faster now :slight_smile: Yes, we should probably support this directly in the API binding, thanks! A local installation would reduce the latency further a bit but we would usually recommend using TestRail Cloud unless you have specific requirements such as integrating with a locally installed issue tracker or LDAP/AD system, for example.

Cheers,
Tobias