nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

practical limit on workarea size?

chuckles

Maybe this is a silly question, but can I expect any performance issues from having 15,000+ files in one workarea? We currently have our content split over many branches, but it is all being maintained by one user group who find it annoying. Also, we are in the process of upgrading to 6.5 and want to capitalize on the new search feature which, as I understand it, creates indexes per workarea and this would let us run one search on everything.

Find more posts tagged with

Comments

cliffhanger

We have few thousand files on one workarea, and see no issue with that. However, whenever number of files in one folder reaches about 1,000 the forms take pretty long to load. Form load time seems to be proportionate to the number of files in the directory.

I believe there's a rule of thumb for <500 files in one directory.

-cliff

ccprofessional

What matters more from a performance perspective is number of un-submitted files.
The 500 limit per dir is an old recommendation for pre 5.5 releases.. in 6.x, its more like a 1000 (approx).

If you have performance issues, I would recommend you contact iwov support, who have access to engineering resources to narrow down the problem.

jed

We have a workarea with ~141926 total files. For the most part, we have not experienced any significant issues (recently). With that being said, it all depends on server hardware, directory structure and teamsite usage. In our case, we have a 12 CPU box w/ 48 gigs of ram. Most installations are not going to be that beefy. The branch also only has one workarea and most of the users work directly on the filesystem.

The only way to know what YOUR system will do is to make the change on a test server and properly load test. This, unfortunately, is not trivial.

--
Jed Michnowicz
jedm@sun.com
Content Management Engineering
Sun Microsystems

nipper

I was on a project with WA about 25K files. No big deal. The comment one the number
of modified files is true. When we did an import, the GUI took a long time to view modified
(something you only do once

)

Our Solaris server was not nearly as big as Jed's. Must be nice to work for a hardware
vendor (unless you want a PC on your desk)

chuckles

Ok, I don't expect that we would have more than 100-200 unsubmitted files at any given time. Sounds like this should work fine. Thanks everyone!

rpatiban

Regarding Search feature: I think, we may do search across multiple workareas in a branch. But we can't search across branches. And your understanding is right on creates indexes but per branch.

Regarding workarea size: As long you consider the number of files in a single folder (as Cliffhanger mentioned), there shouldn't any problem on the whole workarea.

But if you consider the future growth rate of the content, number of editions, and if they are high, I would certainly recommend to devide the content into multple branches in a rational manner. Then you may not be able to take the full advantage of search feature since it searches in the current branch only.

Hope this helps,