Concrete CMS setup – multiple installs on a single site. Why?

Using Concrete / Help
1

Recently started a new job overseeing a large website for a university, and they use Concrete CMS. The way the site is setup seems odd to me – but my background is in design and marketing, not programming and networking. So, I wanted to get some input from those with more experience.

Apparently, they’ve been using Concrete for several years (since 5.7). Each section of the site is a separate Concrete5 enabled directory that shares Concrete5’s core application files using symlinks. All told, there are 130+ instances of Concrete running in this manner. Best guess, we have well over 1000 pages. I can’t tell for sure because with multiple instances I don’t have a site-wide XML sitemap.

The “web blueprint” document that they have simply says the reason it’s set up this way is “These separate CMS instances allow us to utilize the CMS throughout the site while retaining independent CMS users, privileges, pages, and files within each instance.” Another aspect of using these symlinks is that we symlink to different versions of Concrete and can easily upgrade/downgrade one section at a time. It seems to me that most of the reasons given for running these symlinked instance can also be achieved using advanced permissions — except for siloed files and upgrading a section at a time of course.

I have questions about this setup.

Is running 130+ symlinked instances less efficient than a single instance from a server resources standpoint? Or is it about the same?

Are there any other benefits to running 130+ symlinked instances of Concrete? Would it be better to run one instance and use advanced permissions to limit user editing to specific sections of the site?

The most current version we’re using is 8.5.5. We are in the process of upgrading PHP so that we can install the latest version of 9. I’m wondering if now is the time to start reducing the instances of Concrete.

Thanks for any insight you can give.

2

The symlinking of the concrete folder really just sounds like a way to not have to have 130+ copies of effectively the same files, and a nice way to upgrade all instances in one operation.

We don’t do this with the core of concrete, but I certainly do it on my local machine for add-ons - it means I can develop an add-on and test it across different versions of concrete without having to actually copy the package folder and keep everything in sync. The package across multiple installs is the same package. Keeps everything very tidy.

But for all intents and porpoises, this really is just 130 seperate installs of Concrete, in 130 different folders, with 130 seperate databases.

I don’t think there’d be a clear answer about what is more efficient. On the one hand, a single instance means you’ve got one (or a handful of themes) running, so you’ve got one location that scripts and css files are served from, and things might be able to be cached more often.

On the other hand, individual instances mean that each site has fewer pages, and blocks like autonavs may have do less work to filter and output pages.

But it might end up there’s no real difference from a webserver’s point of view - a request comes it, it processes it, connects to the database, generates an output and ends. It really doesn’t matter if it’s one big site, or lots of smaller ones, it still has to process that request and do roughly the same amount of work.

You end up with a lot more database storage, but that’s also not really a problem either, it’s all about database usage. It might be slightly more performant to have multiple databases here, rather than a big one with lots more data in it, but probably not much of a difference.

I think the main question here is: does this setup actually make sense with their website needs? Our experience with universities is that each department can have very different needs (and opinions), and often want a lot of control over their websites. Sometimes there will be a core university website which tightly conforms to branding, guidelines, etc, and on that they’ll have a department page. But then they’ll have off-shoot websites developed where they can have more freedom (especially for shorter-term projects), and those are completely independent of the main site. It also can be political. Universities can be funny places.

Or put another way, what problems would be solved if instances were merged, and replaced with permissions for editing? And what problems/tasks would it create?

3

That’s sort of what I was wondering. Sounds like it’s the same processes running with lots of smaller sites as with one big one, so server load wouldn’t be substantially different either way.

You’re right about the way universities operate. The vast majority of our installs (95-97%) are running the same theme, so that’s not really an issue. It could be that keeping each section from accessing the others files is reason enough.

Great questions. If use of server resources isn’t obviously and substantially better in one large install vs many small ones, ultimately I’d probably be creating more problems than I solve. And certainly more work for myself and staff.

Thanks for your input!

4

I use a linked /concrete directory for a few customers that have multiple sites. Usually one cluster sharing a linked core for the live site and a separate cluster sharing a linked core for the stage/test site. As noted, its a convenient way to keep a bunch of sites on the same version of /concrete.

I also do the similar for /packages on my development system, having clusters of multiple installs across many versions of concrete with one linked /packages directory for testing addons and themes.

Both work conveniently for managing common /concrete or /packages files.

On live sites you need to take care that multiple linked /packages directories still require one license for each package for each site it is installed on. Even if its common files, its multiple sites/uses.

The only disadvantage I find is testing upgrades to /concrete. Its easier to change the /concrete core, but you either end up spending a lot of time playing smoke and mirrors between the various versions of concrete and the various sites to upgrade one by one, or you have a lot of testing to do in one big bang if you update all sites linked to the one /concrete directory in at the same time.