How big is yours? Question about size of projects

[owilkes]

Hi all,

Trying to work out if I should put my (several thousands of pages, and likely to grow quickly) company documentation into one single project, on one SVN repository, with thousands of snippets and images - or split the project into separate streams, including multiple SVN repositories, for purposes of efficiency/scalability.

I'm presuming I should be able to merge the projects together using imports at the end.

I'd like to know - what are the largest Flare implementations out there? Are there any cases of performance issues being encountered beyond a certain size? Are there any benchmarking statistics/algorithms for the processing power required depending on the size of the output?

If you have any achievements to boast, or cautionary tales to tell, now would be a really good time to tell it.

Thanks.

[NorthEast]

We have one 2500 topic project, accessed by 4 authors from TFS source control. Flare has worked fine for us, with no particular problems or performance issues.
In a separate project, I've used multiple (3) project imports to import around 2000 topics in total, again without any issues.


I can't say the same for MadCap Analyzer though (the separate product, not Flare's built-in Project Analysis); it is almost unusable with our 2500 topic project, as it is extremely slow to update statistics (often over 5 minutes), and very frequently crashes (1 in 3 times used) which brings down Flare with it. It seems more stable with smaller projects (e.g. 500 topics).

[nickatwork]

We have just under 2000 topics, roughly 3,500 images.
But I am the only author here, so there is no source control needed.

Flare seems to perform pretty well considering, it has crashed on me now and then, but what program doesn't.

Analyzer used to be pretty much a waste of time, but now I've noticed it working much smoother since the update and I can actually get information out of it without having to wait 30mins to analyse my project files.

The only time I notice a solid slow down is expanding a folder in content explorer that might have loads of files in it, like images, it takes a little while to populate the list - understandably.

[i-tietz]

We have about a dozen Flare projects in the same MS VSS 2005 database. Three of our projects have sth like two to three thousand topics, the others are smaller - they have a few hundred topics.
We keep them in one database because they share files. The files they share are all in one particular project. Those files are linked into the projects that contain the files. That proceeding has the advantage that each project automatically notices when there is a update.

[Andrew]

Hi all,

Trying to work out if I should put my (several thousands of pages, and likely to grow quickly) company documentation into one single project, on one SVN repository, with thousands of snippets and images - or split the project into separate streams, including multiple SVN repositories, for purposes of efficiency/scalability.

I'm presuming I should be able to merge the projects together using imports at the end.

I'd like to know - what are the largest Flare implementations out there? Are there any cases of performance issues being encountered beyond a certain size? Are there any benchmarking statistics/algorithms for the processing power required depending on the size of the output?

In my experience, processing power matters, but not as much as disk performance. If I were spec'ing out new Flare PCs for a project of any considerable size, I'd see if I could get a good solid-state drive from which to run Flare projects.

We have one project with about 7500 topics and about 1.25 million words (and very few graphics, so the actual size on disk is fairly small). It's HTML Help. We don't keep it in source control (yay manual backups!), and up to 3 writers have used it at the same time. We keep it off of our network because performance was pretty bad in the Content Explorer (it's still not great -- one of Flare's weaknesses seems to be the performance of whatever code it uses to show / navigate the Content Explorer -- it's much slower than Windows Explorer).

We have many smaller projects (from 10 to a few hundred topics each). We've also got a master project with a dozen or so sub-projects, each book-length (from 75-600 pages). It takes a long time to build that (maybe 50 minutes), but otherwise, it works fine.

[owilkes]

Thanks for the responses all - it gives me confidence that Flare will be able to handle the volumes we will be dealing with.

We have two main documentation centres - in Europe and Asia - so will probably have two repositories, to save on network considerations, see if that has an impact. Will update this discussion when we have some benchmark results.