Is there a document limit to what MODx can handle

yes, nice experiment and report, thanks alot!

Another interesting bit of cache file related info:

I reduced my modx_site_content table record count to 6,755 - that is the total I will need for all my articles.
My siteCache.idx file is now 849KB, down from 1,558KB I had before. Just this change alone gained me another half second in total load time. (This is time it takes for a cached page to load, no DB calls). Total load time went from roughly 1 sec to 0.5 sec.

This may not seem significant to many, but just thought I’d tell everyone what I see - besides, every millisecond you can gain in page load time is useful. It seems that about every 700KB added to the siteCache.idx file adds about 0.5 seconds load time. I’ve only done these changes on my local server, so take this with a grain of salt.

I haven’t even looked into the cache files, but just a thought that popped in my head. is there a reason each document can’t have it’s own cache in the document? The cache would have to be cleared after almost any edit to templates or the such, but it seems like there would be less overhead on doc render.

Just a thought.

Quote from: JeremyL at Sep 28, 2006, 12:27 PM

I haven’t even looked into the cache files, but just a thought that popped in my head. is there a reason each document can’t have it’s own cache in the document? The cache would have to be cleared after almost any edit to templates or the such, but it seems like there would be less overhead on doc render.

Just a thought.

This already happens. Each document has it’s own cache file, if cacheable; but there is also the siteCache file, which keeps all of the system settings, an index of all available documents, plugin/snippet/chunk content, and some other important properties to reduce database access on each request. This is currently a bottleneck to the sites with significant numbers of pages, as is being discussed here, and code is already being experimented with to address to these issues. There’s always a balance of page rendering/db access performance against file size/memory usage that must be maintained, but I believe with some adjustments to the current page-level caching, and with the addition of object-level caching to help offset the database access vs. code and memory footprint issues, we can come up with ways to easily configure sites to strike an optimal balance between these opposing forces, based on the site’s actual size and usage patterns.

If you have more or other ideas on this subject, feel free to share.