Modifications necessary to handle approx 6000 documents

These ideas all sound fantastic. Gotta love the ModX community where many heads are better than one.

couldnt you also use something like

if MODX is not defined {
exit();
}

Something like that would probably be a good idea to add to the beginning of all custom includes.

(OK maybe the output message should be a tad more informative.)

MODX_MANAGER_PATH is a constant which absolutely should have been set when the config file was loaded, and constants are much more resistant to having their values changed accidentally. Also it seems to me as if there may be some instances in which you’d need to first have a global $modx; statement (e.g., if the include were inside a function) before testing for that object’s existence, and that would defeat the purpose.

This might also be a useful second line of code:

great work guys, thanks so much.

i’d been pulling my hair out because on our site with over 22,000 docs, the cache file was 6mb, but php was allocating over 80mb of ram. now, the cache is loaded into only 9mb. woohoo!

@redman
wow! 22 000! it’s a bit more than 5000
Did you do any hacks on core (besides this) or anything else?

just memcache things as much as possible, and i think the occasional extra index on tables here and there.

Would be interested to know your indexes, and potential pitfalls if doing that to smaller sites.

On a related topic, I wonder if it would be possible/helpful to split the document cache from the Element cache. Snippets, Templates, Chunks, etc. are all far less likely to change frequently, so the document cache file would need to process/write less during clearing the cache. My understanding too is that this might further have benefits with opcode caching like eAccelerator. Thoughts?

Quote from: rthrash at Jun 13, 2009, 09:09 AM

On a related topic, I wonder if it would be possible/helpful to split the document cache from the Element cache. Snippets, Templates, Chunks, etc. are all far less likely to change frequently, so the document cache file would need to process/write less during clearing the cache. My understanding too is that this might further have benefits with opcode caching like eAccelerator. Thoughts?

It is split in Revo, but you still have limitations; the quantity of Documents/Resources is always going to be the bottleneck. Having the elements in the same cache file is more like insult to injury in this case, and though it buys a little more space, the problem is ultimately the same. Once you hit a certain number of them, performance is better without caching the various lists of Documents/Resources at all, especially if you use page caching properly.