to be clearer on the 'over 200 queries' point:

"This has been found to do a separate query for each project in the list when the same data could be brought back in one single query, which should be much more efficient"

Thanks for the bug report.

In the interest of reproducing the problem, what is exactly a "high number of projects open and assigned to different users." ? How many records in mantis_project_table, mantis_project_user_list_table, mantis_user_table ? Would you be able to provide a dump of these (anonymized if needed) ?

As you appear to have already performed the analysis on optimizing the functionality, could you please share the details of your investigation, including the more efficient single query you mention ?

Even better yet, if you know PHP, why don't you submit a pull request or a patch ?

Is this related to or a duplicate of bug 0009876?

Hi there,

Thanks for the replies. We are looking into the comments you've given. It may take a bit of time to get this information together as we have other work priorities. Will let you know.

Thanks again!

We're using MS SQL.

We have (in prod/test):
502 rows in mantis_project_table
404 rows in mantis_project_hierarchy_table with 90 Parent projects
1164 rows in mantis_project_user_list_table
158 rows in mantis_user_table

I don't have access to an MSSQL platform so I'm afraid I can't help you much with this (at least in terms of reproducing the issue).

I ran a quick test after creating a large number (2000) of projects and subprojects, but the performance was fine (page load < 2s) on my dev box (MySQL).

Is there some sort of MS SQL profiling tool you can use to find out the problematic queries/query combinations? We might be able to guess what's wrong and send you a patch for validation.

Please note that I just fixed a performance issue (see 0009876, thanks rombert for pointing this one out).

This may or may not be the root cause of your problem, but in any case I invite you to download the next nightly build (date >= 02-May) or to patch your code with the fix [1] before performing any further testing.

Should the problem persist, it may be useful to temporarily set $g_show_queries_count = ON; $g_show_queries_list = ON; in your config_inc.php. Please be aware that this setting may potentially expose sensitive information to your users, so if you don't have a test system available you may want to change this for your profile only, using the Manage Configuration page.

Once this is done, reproduce the problem and check at bottom of the page for the following information

• any query running for a long time (2nd column)
• last 2 lines (total sql + request times)
  Report the figures here, as well as the relevant SQL statement(s)

[1] https://github.com/mantisbt/mantisbt/commit/cc7703acc8d05f253d52a152a7d8cd0c1c43815d

Hi there,

I'll arrange for this nightly build to be installed on our DEV server to check the results. Thanks very much for all the help so far!

Looking forward to your feedback.

Hi there,

Our developer patched our DEV environment to the 1.2.16 version.

Unfortunately the speed of loading was still very slow with no noticeable improvement, and many queries were still sent to the database instead of just one.

Thanks :)

Could you share the information that dreagd requested at 0015796:0036735

As you appear to have already performed the analysis on optimizing the functionality, could you please share the details of your investigation, including the more efficient single query you mention ?

and also 0015796:0036760

Should the problem persist, it may be useful to temporarily set $g_show_queries_count = ON; ....

Alyndri,

You did not provide any more feedback; I am therefore resolving this issue as "no change required".

Feel free to reopen the issue at a later time and provide the requested information.