Terrible Mantis Performance

[acostin]

Hi,
We're using mantis on our site, and in order to simplyfy the registration process, we've used our users table as the mantis one. But we have 100.000 users.

The performance now is completeyl unusable - it literally breaks our server ...

Is there any place where we could enable an SQL query performance log?

Alexandru

[thraxisp]

There is no SQL log, per se. You can get the timing for all queries by setting the variable $g_show_queries_list = ON; This will display a list of all of the queries run and their timing.

Since you are using your own table, I would suggest looking at whether the indexes are in place, and that mySQL has enough memory to hold them.

[taylorh]

We found the same thing when rolling out v19 to 800 users. The performance difference between v18 and 19 is significant. I chalk it up to the more modular design of v19. Try echoing out something like $t_result in the gpc_get_cookie function, and you'll get an idea of how the new design hurts performance. The cookie var won't kill performance but they do the same sort of thing with calls to the mantis_user_table, etc.

[cristic]

There is no SQL log, per se. You can get the timing for all queries by setting the variable $g_show_queries_list = ON; This will display a list of all of the queries run and their timing.

- We tried this solution but unfortunatelly the SQL log is not offering very much information. Actually there are no information at all because the mantis queries is taken a very small amount of time. The problem appears in the fact that for each page 100 or more queries are executed. This means that for 1 second or more the processor will be 100% occupied by a single process and if there are 50-60 connections simultanous the machine will simply stop responding.

Since you are using your own table, I would suggest looking at whether the indexes are in place, and that mySQL has enough memory to hold them.

- This was our thought too but so we start looking at the indexes and they are all correct. The memory is not an issue as we have tables with more then 4 millions records with lots of indexes used in each page and the problem doesn't appear.

[vboctor]

cristic, when you set

$g_show_queries_list = ON;
$g_show_queries_count = ON;

You should see at the end of each page the list of queries executed and the time take by each. You will also see the redundant queries highlighted in red. Also there will be a count of the total number of executed queries and the total number of unique queries. This information provides us with information about bottle necks, areas that need caching, ...etc.

Please use the above information to provide us with information about:
- Which pages are slow.
- Which queries are causing most of the redundancy.
- Which queries are the slowest.

Note that the performance of Mantis may differ depending on issues like:
- Big number of users vs. big number of issues.
- Anonymous user vs logged in user
- ...etc

I have seen before a lot of redundancy happening one case, but not as much in the other cases.

We usually cache the result of the APIs. This is done in most of the APIs, but I assume there is a couple that are not yet cached. But most of the APIs that access the database has a cache on the page level.

Regards,
Victor
Mantis to Go?
http://www.futureware.biz/mantisconnect

[Guest]

Note that the performance of Mantis may differ depending on issues like:
- Big number of users vs. big number of issues.
- Anonymous user vs logged in user
- ...etc

Mantis performance is an issue for us as well, and the difference between 0.18 and 0.19 (noted elsewhere in this forum) is really noticeable. After a quick-and-dirty test, it seems to me that the biggest bottleneck is on the bug list page when

(1) viewing it for the first time (Mantis cache expire?) -- on our site I get 622 total queries executed, 71 unique queries executed with first-time view vs. 79 total queries executed, 70 unique queries executed when logged in on the view all bugs page. The single most redundant query in the first case is SELECT id, cookie_string FROM mantis_user_table WHERE username = "guest".

(2) there is a long list of bugs, since for each bug the Updated field needs to be selected -- like SELECT last_modified FROM mantis_bugnote_table WHERE bug_id='nnnn' ORDER BY last_modified DESC repeated 50 times.

I posted zipfiles of pages with queries dumped on my Mantis usability review page http://wiki.kiv.zcu.cz/PremekBrada/Mant ... lityReview for a reference.

Hope this can help,
Premek

[br8kwall]

We support about 20 users here on a very modest box with perfectly adequate performance. Though we have taken to setting up a new mantis install for each project to reduce the number of users/bugs in each instance.

I'm wondering if upping the mysql query cache memory limits might help performance in these situations. Of course this only helps if the exact same queries are being run in quick succession.


http://www.databasejournal.com/features ... hp/3110171


http://dev.mysql.com/doc/mysql/en/query-cache.html

[vboctor]

Mantis 1.0.0a3 has several performance enhancements compared to 1.0.0a2, can you please test the performance of it and give us some feedback.

Regards,
Victor.
Blog
http://www.futureware.biz/

[frentmeister]

Mantis 1.0.0a3 has several performance enhancements compared to 1.0.0a2, can you please test the performance of it and give us some feedback.

Regards,
Victor.
Blog
http://www.futureware.biz/

Hey Victor, we have a lot of Performance Problems with 1.0.0.a3, the Problem is we have a lot of Testers (>5000) , one of the Problem ist, that Releationships (in a Issue) dont sort, the long list loaded more than 50 Sek.