Having too many nested cases can result in slow
loading. The problem appears to be PHP-bound, in the
tree-construction phase. Is there a better way to
generate such a tree?
It's probably not so much the PHP's fault.
The testtree() recursive function, in one iteration,
performs six database-hitting function calls. 2 or 3 of
these should be defined at the beginning of project.php. The
other 3 could possibly be loaded into caseary() somehow as
part of the initial population query.
Start with moving some of the project-global values out; see
how much that helps.
Quite likely however it is the calls that deal with the
results table (latestver(),lateststate()) that probably have
the biggest load.
It's becoming common in some applications to create
"current" tables, with one row per key, which are updated at
change time. This requires more database space and more work
at change submit time, but eliminates the max()ing done
later in order to find current. This may be a good
consideration.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
permission() and newestver() are project-specific, so could
and should be loaded at start of script. A lookup array of
version names, which is a project-specific set, could also
be loaded earlier, and looked up via array index instead of
a db lookup. This would be OK, as long as the set of
versions in the project history aren't very big.
One additional thought about moving to "current table"
paradigm for results table is that we could use the same
paradigm on tests table to introduce TC change history. When
TC is edited, the existing def is retained in history table,
and current def is in current table. Slightly different
usage (in results, it would be upon add, but in tests, it
would be upon edit), but same paradigm underneath.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
lateststate() can be optimized with a specific fix and it paid dividends for us. latest state recurses through all child test cases of the test to determine its pass/fail state. it does so because if its to be in the "passed" state it needs to examine all children to make this determination. however if there is a failing child, it keeps searching through all the child nodes. Once you have a failing child test you can exit this method because you don't need to keep looking
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=579274
It's probably not so much the PHP's fault.
The testtree() recursive function, in one iteration,
performs six database-hitting function calls. 2 or 3 of
these should be defined at the beginning of project.php. The
other 3 could possibly be loaded into caseary() somehow as
part of the initial population query.
Start with moving some of the project-global values out; see
how much that helps.
Quite likely however it is the calls that deal with the
results table (latestver(),lateststate()) that probably have
the biggest load.
It's becoming common in some applications to create
"current" tables, with one row per key, which are updated at
change time. This requires more database space and more work
at change submit time, but eliminates the max()ing done
later in order to find current. This may be a good
consideration.
Logged In: YES
user_id=579274
Specifically the calls made by testtree() are:
latestver()
lateststate()
newestver()
getvname()
isassigned()
permission()
permission() and newestver() are project-specific, so could
and should be loaded at start of script. A lookup array of
version names, which is a project-specific set, could also
be loaded earlier, and looked up via array index instead of
a db lookup. This would be OK, as long as the set of
versions in the project history aren't very big.
One additional thought about moving to "current table"
paradigm for results table is that we could use the same
paradigm on tests table to introduce TC change history. When
TC is edited, the existing def is retained in history table,
and current def is in current table. Slightly different
usage (in results, it would be upon add, but in tests, it
would be upon edit), but same paradigm underneath.
Logged In: YES
user_id=47323
Originator: NO
lateststate() can be optimized with a specific fix and it paid dividends for us. latest state recurses through all child test cases of the test to determine its pass/fail state. it does so because if its to be in the "passed" state it needs to examine all children to make this determination. however if there is a failing child, it keeps searching through all the child nodes. Once you have a failing child test you can exit this method because you don't need to keep looking