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

Performace Issue


#1

Hi,

We are experiencing a longer response time (20-30secs) when accessing TestRail after long periods of inactivity. TestRail is hosted on windows server 2008/IIS web server/SQL Server 2005. Are there any IIS settings or something else that could fix this problem?

I appreciate your help. Thanks in advance.


#2

Hello Dashesh,

Thanks for your posting. Do you see this behavior with every machine you access TestRail from or just a few? This may be a DNS issue if this happens only after some inactivity (i.e. the initial lookup for the server name to the IP may take a long time). I don’t think this is directly related to IIS but this could also a performance/caching issue if the server is “cold”. Could you please check with your IT department if this may be related to the DNS lookup?

You can also enable logging for your TestRail installation to check how long the initial request takes on TestRail’s side:

http://docs.gurock.com/testrail-faq/system-debug

(besides debug information, the log also contains the execution times for the requests)

Thanks again and I look forward to your reply.

Regards,
Tobias


#3

Hi Tobias,

I am working with Dashesh on this issue.

We will enable the TestRail logging and accumulate data from 6 different users (3 regular users and 3 light users. 6 different desktops). Then, we will provide the response time it gathered.

Related information:
Since the number of users is relatively small and the web server will be only available within our intranet, we are not concern about the network traffic to this server. Currently, we only have TestRail running in IIS and the only other application we planned to deploy with is Redmine.

By the way, we are using virtual machine to evaluate TestRail. We didn’t request a DNS A record through our IT department. All users are accessing the server via IP address (http://xxx.xxx.xxx.xxx/ since using the default web site port 80). Also, we are seeing this occurred within the server via http://localhost/ or directly http://localhost/index.php?/auth/login.

I am looking into IIS configuration since I suspect it is the source of this behavior. So far, I didn’t find any potential setting may resolve this.

By the way, we have similar issue with our temporary Redmine server (RoR + Mysql + Thin + IIS) use for TestRail evaluation/integration test. It is located on a different vm. Due to minimal amount of traffic on that server, the idle timer for the corresponding application pool worker process is disabled in IIS. It resolved the issue of ‘slow/warmup’ required after long inactivity in Redmine. Same setting didn’t resolve the similar issue with TestRail.

It is not a significant issue but just an annoying one.

Regards,
John


#4

Hello John,

Thanks for the additional information. This can certainly also be related to using a VM. For example, if your virtualization server hasn’t enough resources to keep all VMs in memory and needs to swap out certain VMs from time to time, this may explain the “cold cache” behavior on the first request and this couldn’t be solved by adjusting IIS or SQL Server settings. Could this be the case?

Regards,
Tobias