ZODB and mounting points

Plone Support Administering Plone sites
1

We have a customer that is used to create their Plone sites on the same Zope using multiple mounting points and I want to understand what are the advantages/disadvantages of this approach.

Unfortunately there's not much information about this topic on the internet and an article that is cited many times seems to be lost:

http://plone.org/documentation/how-to/multiple-plone-sites-per-zope-instance-using-separate-data-fs-files-for-each-one

Is somebody here using that approach? Is this considered a good practice? why?

Thank you in advance for any information you may share.

2

The main advantage is that you've smaller files and you can pack one site at a time. Also you can isolate bad sites, or put some files/sites on faster filesystems. Disadvantage is when you want to merge them in one file, you've to copy/paste I suppose (but never tried).

3

http://web.archive.org/web/20080611061803/http://plone.org/documentation/how-to/multiple-plone-sites-per-zope-instance-using-separate-data-fs-files-for-each-one

1 Like
4

Dont copy / paste content with blobs from one mount point to another, it will give you big problems.

5

I have running different Plone Sites in one Zope but the Sites are not so big, so i have no experience with Load.
I configure my Mountpoints via buildout.cfg:

[buildout]
....
parts =
    filestorage
    your parts ...
    backup

[filestorage]
recipe=collective.recipe.filestorage
zopes = instance
blob-storage = ${buildout:var-dir}/%(fs_part_name)s/blobstorage
location = ${buildout:var-dir}/%(fs_part_name)s/filestorage/Data.fs
zodb-container-class = OFS.Folder.Folder
parts =
    site1
    site2
    and so on.....

[backup]
recipe = collective.recipe.backup
datafs = ${buildout:var-dir}/filestorage/Data.fs
blob-storage = ${buildout:var-dir}/blobstorage
location =${buildout:backups-dir}
blobbackuplocation = ${buildout:backups-dir}/blobstorages
additional_filestorages =
    site1$ {buildout:var-dir}/site1/filestorage/Data.fs $ {buildout:var-dir}/site1/blobstorage
    site2 ${buildout:var-dir}/site2/filestorage/Data.fs $ {buildout:var-dir}/site2/blobstorage

Note: filestorage-part should be / must be the first entry in the parts-list.

In the ZMI you can add the Mountpoint via Dropdownlist in the Right-Top Corner.
My greatest Problem is that Sitelayouts from the plone.app.mosaic AddOn are available in all Sites. But i think this is a misconfiguration of myself. I have copy only the Folder ${buildout:var-dir}/site1 to a new Installation, Zeo or Standalone, no Problems.

6

We do this for all our sites. It isolates the caches so one site can't push
out the cache of another. And moving a site from different setups is easier
ad you can use the whole data.fs if you want.
Our setup is we have number zodb slots 1-20 setup from the start and make a
new site in thr next slot when we get a new customer. No deployment needed.
Disadvantage is that it uses more ram so each cache js separate. To reduce
you have time each cache size. If its rarely used site you can't let the
cache swap it out. There is also an io problem if you use a single zeo
since. With many a sites plus zrs is a lot of connections. This can be
mitigated my using different zeo per db which shoukd improve performance.
We haven't tried yet though.

7

I'd like to add to the question/discussion here. Traditionally we've had about 100 sites in a single Zope using multiple mounted databases, but not one per site. It's mostly arbitrary but it's somewhere around ~10 per. Previously we were using postgres with Relstorage but have since returned to ZODB.

Lately I've been regretting having multiple sites on the same database. In (way) earlier versions of Plone copying a site with zexp worked fine but this strategy is not desirable with zc.relations (among other problems) because all of the intids break on changing databases. Really the only way to copy a site to another database is to copy the entire db + blobs. I see this advice reflected in the docs as well. Having one site per db would give me a lot more control not just for backups, but to pull data from production to create a staging environment for each site.

It sounds in this thread like people who are doing one db per site are not doing it with around 100 of them? I expect a minor annoyance from having to run buildout to make more dbs available but are there any performance problems here? Can the number of mounted dbs per Zope scale indefinitely or would it make sense to create additional Zope/ZEO setups?

8

On my experience in one zope with above 100 sites (140? I cannot recall), I got an error along these lines "Too much connections opened". Maybe you can configure it somewhere to go higher.

100 sites looks way too much for me, I guess it depends on the traffic sites have.