Mantis Bugtracker 

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004124TestLinkReportspublic2010-12-23 17:052010-12-29 18:12
Assigned Tofman 
PlatformOSOS Version
Product Version1.9 (Prague) 
Fixed in Version2.0.0 (planned) 
Summary0004124: General Test Plan Metrics Fails (BLANK Page) with HUGE amount of test cases
DescriptionI've been having many issues with 1.9 specific to Platforms/Users/Test Cases. The issue I'm now experiencing is that if i have multiple builds of a test plan that contains 5 platforms I cannot get the General Test Plan Metrics to return data, the query finishes running and the results screen is empty, no errors on browser, db, etc
Steps To Reproduce 1. Create a test plan with 5 platforms
 2. Assign 500 test cases to each platform
 3. Assign a 5 different users test cases for each platform
 4. Create build 1
 5. Click General Test Plan Metrics(1)
 6. Create build 2
 7. Click General Test Plan Metrics(2)

Expected Result
 1. Results page is shown
 2. Results page is not shown
Additional InformationI've been providing db for triage for other problems in 1.9, let me know if you need a copy. Also, Results by Tester per Build never returns with results. The query metrics, test case assignment overview are displaying fine. I've tried to analyze slow running queries in MySQL and I can't get it to work. Also, CPU is being spiked my MySQL during these actions
TagsNo tags attached.
Database (MySQL,Postgres,etc)MySQL 5.4
PHP Version
QA Team - Task Workflow Status
Attached Fileszip file icon [^] (16,982 bytes) 2010-12-25 10:17

- Relationships

-  Notes
fman (administrator)
2010-12-23 20:04

have you tried with say just 50 test cases ?
bizob28 (reporter)
2010-12-23 20:41

I have and it is ok. I think adding another build just exponentially added what is being reported in General Test Metrics. I'm able to have multiple builds of 2 platforms with 500 test cases so it seems it's failing between 2,500 & 5,000
fman (administrator)
2010-12-24 08:23

please send DB copy
fman (administrator)
2010-12-24 08:30
edited on: 2010-12-24 08:32

How many executions for each test case on each build ?
How many test suite levels ?
How many top level test suites ?

fman (administrator)
2010-12-25 10:17
edited on: 2010-12-25 10:58

try with attached fix and let us know
You need also to increase timeouts on php.ini

bizob28 (reporter)
2010-12-27 14:36

this fix seems to have to worked. I'm logging another ticket regarding calculations of the general test plan metrics, they are wrong.
bizob28 (reporter)
2010-12-27 16:37

I actually was able to get this working, but now it returns a blank page again, I set mysql.connect_timeout to -1, so not sure what is the problem now
fman (administrator)
2010-12-27 17:23

how have you set time outs on php.ini ?
bizob28 (reporter)
2010-12-27 17:33

mysql.connect_timeout = -1. According to the php.ini that is a way to disable timeouts completely
fman (administrator)
2010-12-28 18:21

what about PHP timeouts ?
terryzuo (reporter)
2010-12-29 01:17

I also encountered this issue before, but it's OK when I changed the timeout value in php.ini(to 3600) as it is a slow query.
I suggest you can open the slow-query-log option and see what's the problem.
fman (administrator)
2010-12-29 08:09

Issue is more related to PHP process time that slow query
bizob28 (reporter)
2010-12-29 14:10

I don't agree with resolving this as a php issue as the query was written in TestLink. To me this is a scaling bug related to TestLink. Unless you are marking this as wont fix because you didn't design TestLink to scale. I wanted to upgrade to 1.9 because of this platform feature, but it is not usable for our company as our testplans usually contain anywhere from 100-2,000 test cases.
bizob28 (reporter)
2010-12-29 15:36

also, pardon my ignorance but when you are referring to timeout value in php.ini, are you talking about max_execution_time?
fman (administrator)
2010-12-29 18:11

I do not like your note 13130.
I've work 1 day trying to solve this, and provide a fix, tha reduced processing time.
From my findings problem IS NOT ON QUERY but on processing we done on PHP.
If you are able to provide me with elements that proof that query is the problem this info is welcomed.
Increasing timeouts has to help to solve this NOW.
In future we will try to refactor if possible to improve this, but right now for me issue is closed.
Having test plans with 2000 test case with several builds, with several executions create lot of data to analise, and this is what make this page process for long time.
You need to increase ALL PHP EXECUTION related timeouts (seems they are only two).
fman (administrator)
2010-12-29 18:11

Till time to refactor : solved with fix and increase in PHP timeouts

- Issue History
Date Modified Username Field Change
2010-12-23 17:05 bizob28 New Issue
2010-12-23 20:04 fman Note Added: 0013086
2010-12-23 20:41 bizob28 Note Added: 0013088
2010-12-24 08:23 fman Note Added: 0013102
2010-12-24 08:30 fman Note Added: 0013103
2010-12-24 08:32 fman Note Edited: 0013103 View Revisions
2010-12-25 10:12 fman Assigned To => fman
2010-12-25 10:12 fman Status new => assigned
2010-12-25 10:12 fman Summary General Test Plan Metrics does not returns blank => General Test Plan Metrics Fails (BLANK Page) with HUGE amount of test cases
2010-12-25 10:17 fman File Added:
2010-12-25 10:17 fman Note Added: 0013109
2010-12-25 10:17 fman Status assigned => feedback
2010-12-25 10:58 fman Note Edited: 0013109 View Revisions
2010-12-27 14:36 bizob28 Note Added: 0013116
2010-12-27 14:36 bizob28 Status feedback => assigned
2010-12-27 16:37 bizob28 Note Added: 0013117
2010-12-27 17:23 fman Note Added: 0013118
2010-12-27 17:33 bizob28 Note Added: 0013119
2010-12-28 18:21 fman Note Added: 0013121
2010-12-29 01:17 terryzuo Note Added: 0013123
2010-12-29 08:09 fman Note Added: 0013126
2010-12-29 08:09 fman Status assigned => resolved
2010-12-29 08:09 fman Fixed in Version => 2.0.0 (planned)
2010-12-29 08:09 fman Resolution open => fixed
2010-12-29 14:10 bizob28 Note Added: 0013130
2010-12-29 14:10 bizob28 Status resolved => assigned
2010-12-29 14:10 bizob28 Resolution fixed => reopened
2010-12-29 15:36 bizob28 Note Added: 0013131
2010-12-29 18:11 fman Note Added: 0013132
2010-12-29 18:11 fman Note Added: 0013133
2010-12-29 18:11 fman Status assigned => closed
2010-12-29 18:12 fman Resolution reopened => fixed

Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker