View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008850||mantisbt||performance||public||2008-02-01 11:12||2019-07-05 04:44|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0008850: 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.
|Tags||No tags attached.|
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.
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.
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.
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.
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.
Sorry - forgot to say... The table that effects the efficiency is mantis_project_hierarchy_table
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.
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.
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
MantisBT: master 0ac196a4
Paul RichardsDetails 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
|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|
|2008-02-01 11:12||djidave||New Issue|
||Note Added: 0019944|
|2008-11-19 11:22||djidave||Note Added: 0019945|
|2008-11-23 07:11||tmatijas||Note Added: 0019997|
|2008-11-23 11:40||tmatijas||Note Added: 0019998|
|2008-11-23 11:43||tmatijas||Note Added: 0019999|
|2008-11-23 12:17||tmatijas||Note Added: 0020001|
|2009-02-24 14:49||daviddre82||Note Added: 0020931|
|2009-02-26 11:18||daviddre82||Note Added: 0020952|
|2009-04-05 12:10||Changeset attached||master 0ac196a4 =>|
|2019-07-05 04:44||dregad||Relationship added||related to 0025901|