> If you are just evaluating, it might be worth looking at git trunk. On top of that I've got a couple of development branches at the moment that are works in progress that might have a knock-on effect of optimising some things ( http://git.mantisforge.org/w/mantisbt/paul.git - two branches - one that starts to change the way we handle dates, and the other BugData objects)
>

> I will get your git repository and try it out.

The main git trunk lives at http://git.mantisbt.org/ and is probably better for now for testing.

>
>
> In terms of your data set, I think you might currently be going to hit a couple of issues:
> a) we kick off a call to project_cache_all (which does a SELECT * FROM mantis_project_table) for any page hit
> --> Reason: that's 'quicker' as the dropdown box to select projects generally requires all projects to be loaded, but for this case...

> Would it not be better to cache only those projects that the logged in user is allowed to see.

That's what i'm wondering, hence my second question :)


> b) The project select box - I assume currently only shows 2-3 projects per user?

> Yup. thats correct.
>  
>
>
>
>

> c) Filters (view issues page) - I believe the AJAX dropdown selectors to search by reporters includes *ALL* users (i.e. 17,000). Someone has submitted a patch into www.mantisbt.org/bugs suggesting that we limit the reporters to reporters linked to the projects a user is related to, or similar.

> Good idea. I havent tried this one yet.
>  
>
>
>
>
> At the moment, the things i'm aware of that i'd like to try to optimise, but haven't done are:
> a) large number of viewable projects
> b) subprojects hierachies
> c) generated emails with large numbers of linked people.
>
> I'd be interested to know if the latest development code also shows out of memory errors assuming your just testing this.
>
> Out of interest, given you are running php 5, what is your php memory limit set to? I know that php group changed the default limit from 8MB to 128MB as php5 itself requires more ram than php4.
>

> The default memory_limit was set to 16MB which I have raised to 140MB just to get it working but for production I will set it back to 16MB.

~16MB is probably fine, you *might* find you need a bit more in some cases of for some scripts.

What we've found helps mantis a bit in some cases is running the APC opcode cache pecl extension, and we currently run that on our /bugs installation.

> Like I said before, for most use-cases the software works fine but in my test-cases its pushing the limits.
> I am not sure if it is necessary to do these optimizations for so large datasets but if you think it may be useful, I can give a helping hand. Its the least we can do to give back to the software we have been using for years.

As long as it doesn't slow down (at least not in a noticeable way) the default case - for the sake of argument, that's 1 project, 20 users and 200 bugs, I dont think it's unreasonable to optimise for these larger cases - especially given that in some cases by analysing whats slow for a large install, we might actually speed up the whole product.

Paul