View Issue Details

IDProjectCategoryView StatusLast Update
0008850mantisbtperformancepublic2019-09-18 10:56
Reporterdjidave Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version1.1.1 
Summary0008850: Split Manage Projects into Pages or Drilldown

We use mantis to manage a lot of small projects which are grouped together under system projects.

We have about 100+ projects and it takes about 15-30 seconds to load the page, which when jumping between projects to make changes seems a long time.

Can this be made quicker by only displaying so many per page or just showing the top level projects and allowing a drill down.

I know everyones requirements for the system are different, so I am not saying this would be useful in all cases, therefore a configuration parameter for how many projects a page could be used to turn of the paging.

We are looking at putting even more projects into the system in the future.

Steps To Reproduce

Just clicking on Manage Project with over 100 projects loaded.

TagsNo tags attached.


related to 0025901 acknowledgeddregad Manage project page loads ALL users 
related to 0026157 new edit project: better (quicker) access to "add version" 




2008-11-19 11:12

reporter   ~0019944

djidave I found this same problem. The manage_proj_page.php is querying the DB project structure a number of times. Mantis normally uses a caching technique for this structure, however this cache is reset when the query is forced to include private projects.
I'm not really sure what the purpose of this cache reset was/is, but I have tweaked the page generation a little to solve the problem.

With the file manage_proj_page.php (released in Mantis V1.1.2) there is a line

$t_subprojects = project_hierarchy_get_subprojects( $t_project_id, true );

I simply removed the second parameter from this call. In addition to this I added the following line, just before entering the while loop to generate the project structure:

project_hierarchy_cache( true ) ;

This worked for me, I can post a patch file if another solution hasn't already been implemented in a future Mantis release.



2008-11-19 11:22

reporter   ~0019945

Thanks CodeCutter

The fix above has worked in Version 1.0.3, the speed has increased from 30 seconds to about 2 seconds.

Sound like the reason you wouldn't want to cache private projects is to stop users who don't have access to them from see them in the cache. We don't have any private projects so this is not an issue for us.



2008-11-23 07:11

reporter   ~0019997

Please add dif or just a simpe explaination of what" second parameter " is.. Sorry I am new to php and file I kind of have a hang of it, I dont understand the terminology yet. Is 2nd peramiter the "true" which would make line 1 $t_subprojects = project_hierarchy_get_subprojects( $t_project_id ); then followed by project_hierarchy_cache( true ) ;

I tried this in 1.1.4 and so no effect. 4 seconds to load 240 projects in project manager..

Also, is there a rework that will break projects down by alpha order like with users? I have about 2000 projects to import from another BT. I tried it and found pages took way too long to load. Project manager took like 120 seconds and it slowed just about EVERY page in mantis down to at least 6 second load times because the projects dropdown was so populated that it took the browser forever to load the page. I think this was way too much for any drop down even if just static HTML. So ideally, break project dropdown alphabetically as well.



2008-11-23 11:40

reporter   ~0019998

Amazeing.. I am running a test which has about 2000 projects and organized into 8 SUBFOLDERS.. Performance time dropped from about 2 seconds load time to 30 seconds when I put all the projects into subfolders.. I actually expected an improvment and NOT a loss. After that, nothing in this forum helped improve. However, get this. I changed the type of table from myISAM to innoDB in phpmyadmin just for shits and gigles after optimize did nothing.. Performance is down to 3 seconds now. Bet I can make better if I optimize my.ini for innoDB.

Warning. No idea what effect this will have in database. Use with causion.



2008-11-23 11:43

reporter   ~0019999

Sorry - forgot to say... The table that effects the efficiency is mantis_project_hierarchy_table



2008-11-23 12:17

reporter   ~0020001

Oh yeah - if I drop supprojects and empty project hierarchy table all togther on my 2000 project build, page load time goes down to about 1.20 seconds from about 2.5 to 3.. However, with only 200 projects, I was getting .20 seconds which is MUCH FASTER... So ON MY SETUP - 6% longer load time for every 200 projects if you DONT use subprojects. If you do use subprojects. 12% longer for every 200 projects IF AND ONLY IF you convert hierarchy table to innoDB from myISAM... If you DO NOT convert to innoDB, forget it. GOes up to like 90% longer for ever 200 projects and takes like 30 seconds to load news page and a whopping 180 seconds to load project manager. This onlu hold true on my system if change is NOT exponential.

Is this becuase the subprojects draw array is somehow different than just projects? I dont understand. I was thinking subprojects would actually reduce load time.

Conclusion - mantis is not very scalable to lots of projects.. need improvement.

I am going to open a new ticket on this.



2009-02-24 14:49

reporter   ~0020931

I ran into this same limitation when i reached about 100 projects now the bottom of the 'manage projects' page is not showing all the projects i have addeded, is there any workaround for this limitation? i would hate to loose all the work i did creating all these projects.



2009-02-26 11:18

reporter   ~0020952

i found the problem i had, i had top change the databases tables engine from myisam to innodb that improved performance and displays all my projects

Related Changesets

MantisBT: master 0ac196a4

2009-04-05 15:54:24

Paul Richards

Details Diff
Sync my working checkout of misc performance changes/mssql fixes:

1) add some caching around version/categories/projects to speed up projects with a large number of categories/versions etc
2) database_api: improve db_fetch_array when running under pgsql
3) tag_api: fix for mssql+mysql by implementing different query logic :(
4) manage_proj_page: add improvement noted in bug 0008850
Affected Issues
mod - core/news_api.php Diff File
mod - manage_proj_page.php Diff File
mod - roadmap_page.php Diff File
mod - core/category_api.php Diff File
mod - core/summary_api.php Diff File
mod - core/helper_api.php Diff File
mod - core/user_api.php Diff File
mod - core/version_api.php Diff File
mod - summary_page.php Diff File
mod - core/database_api.php Diff File
mod - changelog_page.php Diff File
mod - core/tag_api.php Diff File
mod - core/project_hierarchy_api.php Diff File