From: Paul Richards <paul@ma...> - 2009-06-03 23:49:57
----- "Gianluca Sforna" <giallu@...> wrote:
> On Tue, Jun 2, 2009 at 9:47 PM, John Reese <jreese@...>
> > Anyways, I'd appreciate if someone could look at my code and double
> > check it to make sure I'm not going insane. I did some preliminary
> > testing on my on local installation, and it seems to be working
> > correctly, but for something this sensitive, I don't want to just
> > it on master without agreement from others.
> Ok, I had a look at the patch and it looks sane. Some local tests
> succeeded, but (as usual) caching is evil on memory consumption and I
> fail to run the code on larger issues (like #4286)
> Longer term, I think we need to plan a different approach to data
> Thanks for looking into this
Memory's fairly cheap - db queries / disk io / cpu are potentially more expensive.
In php5.3 - the mysqlnd driver memory usage will be included within the php memory limit instead of seperately - i'd be inclined to think there's a reason that the php group have changed the limit from 8MB to 16MB(php5.2) to the current default of 128MB. That's not saying that every request will use >16MB ram (most requests fit in around 12MB).
But personally, I don't see trying to make mantis fit in 16mb of ram is realistic. Take the graphs you can display - a graph that's 300 x 270 pixels x 256 colors, if my maths is correct is going to require 20MB to generate - at a guess, we'd require roughly ~35MB of ram to generate that graph. That's more than any caching we currently do uses.
For the most part, as we only cache what we've already loaded into php (for example a username of the bug submitter), or a list of projects (normally 1-2?) the overhead of caching isn't necessarily that high at the moment, as we're only storing an existing value that may or may not be free()-able by php if not cached (as it could be referenced elsewhere anyway).
If memory is *really* an issue, probably the biggest area we could save memory right now would be by patching adodb to not require/include classes that we never use. I'd estimate we could reduce my 12MB mentioned above to 9/10MB by doing that exercise, which would be the biggest saving, but I'm really not sure it's worth maintaining a fork of adodb to save 2-3MB of ram...