 |
Perhaps performance could be boosted by using some indexes. Currently there are only a few primary keys. |
 |
Making it a configurable option would be even better. |
 |
We should compress the resulting HTML before sending it to the browser. This can be achieved by simply adding 'ob_start("ob_gzhandler");' at the start of the php script. We should do some testing whether it should be done for all Mantis pages or only for heavy ones like View Bugs and Summary. I did some testing on a local installation and there was considerable improvement. I believe compression will be even more effective when using mantis from an Internet server. |
 |
Compression will marginially improve things but will be better for dialups. The problem I think mantis has is in the database access, not the shipping of data accross the network. I'm running mantis on a win2k box on an intranet. We have about 10 users, 6 projects and 500 issues and it feels a bit on the slow side considering the high bandwidth and small installation. I'm glad to see that a time field has been added to the bottom of the footer. This will surely get people to be sensitive to speed. |
|
|
The html output buffering and compression is now supported. This feature requires PHP 4.0.4. To turn this feature on set $g_compress_html = ON. This is in the code now, and will be shipped with 0.18.0. Also did an optimisation on one of the queries. However, there is more work to be done to optimise the database access as rep mentioned. edited on: 06-06 22:45 |
|
|
MySQL offers the EXPLAIN SELECT option to get more information about how queries are execute and which indexes are used. This should be helpful when looking at the queries which most surely are the bottleneck in here. btw: the timestamp in the footer could be cut to 2-3 digits after the comma. edited on: 06-07 02:56 |
|
|
You have a problem with sub pico second timimg? => |
 |
Indeed more indexes are in order (specifically "mantis_bugnote_table.last_modified"), but let the authors complete the next round of overall design before we specify the new indexes. edited on: 06-07 07:08 edited on: 06-07 07:09 |
|
|
After backing up your data, try these ALTER TABLE statements. Please, PLEASE report any changes in display speed in this bugnote thread. edited on: 06-07 10:04 edited on: 06-07 10:05 |
|
|
The SQL code in CVS has been modified to add these new indexes on install. There is also an update file as noted in a previous bug note. |
|
|
What was the timing difference on these changes? The clock tells the real story! Is there a test data set where we can get a good idea of the speed delta to validate that this change addresses the speed issue? I get this feeling that we are shotgunning this problem instead of really going after the root cause. |
|
|
I do not have a large enough set of data on my CVS test data or my two real installs of Mantis to measure a difference. I was hoping the bug reporter would be the one to try the ALTER TABLE statements, but I understand they may not want to mess with an otherwise working system. I choose the indexes after examining every select statement I could find in the Mantis code. I am not done yet as the mainline developers are considering a few changes to the database schema. Rest assured I am not shotgunning the problem. Several strategic indexes were missing and we probably need a few more for the rollout of 0.18.0. Sincerely, |
|
|
Also, moving styles in a css, would keep from sending styles every time. And would allow a choice in available presentations (with alternate stylesheets)... |
|
|
Prescience is already working on the CSS thing :) |
|
|
This should be fixed as of 0.18.0a2. I will leave it to jfitzell to resolve. |
 |
well it's a bit subjective, but I think we can consider this closed for now. |
- Anonymous
