Additional information: this happens on 1.2.1.

And my php log tells me, that most of the time the problem is because of this line in session_api.php (line 154): $_SESSION[ $this->key ][ $p_name ] = serialize( $p_value );

Edit: removed typo

Can you share the contents of your config table? Alternatively, please attach the result of loading the page with xdebug profiling enabled ( http://xdebug.org/docs/profiler ).

I attached an output file of xdebug profiler. Because the file has a size of around 34 MB, I had to pack it. I hope this is ok.

One additional information: every time I reload the page, it gets slower. It's slowing down approx. 2 to 5 seconds per reload. When I close the browser (Firefox 8.0), wait for some time, open the browser again and reopen the config page, it loads very much faster (around 5 secondes for the first time, I think).

Thanks for the profiling output. It seems that printing a button ( for each modified configuration option ) triggers a lot of work behind the scenes, which creates performance problems. I do not have an immediate solution, but I'll target this towards 1.2.x .

Thanks for your feedback!

Edit: it seems that commentig out the lines in adm_config_report.php where the button is generated fixes the issue temporary. Now the duration for page load is constant or even decreasing a little bit. I know that this is just a temporary solution, but for now it's perfect for me.

Again, thanks for investigating!

Maybe another workaround:
If you want the buttons and can live with a possible security risc (protection against Cross-Site Request Forgery) add the following line to config_inc.php
$g_form_security_validation = OFF;

The bottleneck is actually the serialize/unserialize calls performed while storing/retrieving the token from the PHP session.

Maybe we could shift to json encoding to improve performance ?

https://bugs.php.net/bug.php?id=51267
http://stackoverflow.com/questions/804045/preferred-method-to-store-php-arrays-json-encode-vs-serialize

Our CSRF support at present is far from being user friendly or sane from a performance perspective. There is no reason why we need multiple CSRF tokens per page load. We don't even need a unique CSRF token for each page load. This is something we need to fix in a future release.

@dhx I suppose you were referring to https://github.com/mantisbt/mantisbt/commit/a45d0ef551e9359d3a469287f5de8ef08096e12f ?

I have implemented basic filtering on the manage config page which I believe would be an effective workaround for the performance issue reported here, thanks to the default filter criteria.

Please have a look at https://github.com/dregad/mantisbt/tree/manage-config - testing and feedback would be appreciated.

@dregad: Thanks for the reminder and proposed patch. I've reviewed https://github.com/dregad/mantisbt/commit/db0e3d3b103750197cbc656323ff2984f803fa47 and it looks good to commit. Keep up the good work :)

Thanks for feedback dhx.

For the record, I did some benchmarking for this patch, using a sample DB having a bit less than 700 records in mantis_config_table, configuring the filter as appropriate to display all of them, for the following branches:

baseline: current 1.2.x branch HEAD (commit 66050dc2)
case 1: filter branch https://github.com/dregad/mantisbt/tree/fix-14559
case 2: performance fix branch https://github.com/dregad/mantisbt/tree/fix-13680

Average execution times on 3 runs (as reported at page bottom by $g_show_timer) are as follows:

baseline: 13.3 seconds
1: 20.1 seconds (due to displaying 2 buttons per line instead of 1)
2: 1.4 seconds

I have a bit more testing to do on other aspects of the feature branch https://github.com/dregad/mantisbt/tree/manage-config before merging.

Marking as 'acknowledged' not resolved/closed to track that change gets ported to master-2.0.x branch