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; } } }

Reverse deployment 'committing' behaviour

System

Hi DevNetters!
I'm running a reverse deployment that pulls content from a remote system into the TeamSite repository that's co-resident with the OpenDeploy Base Server.

This is eventually working correctly, but the portion of the deployment that is represented by 'committing' when viewing the deployment in the OpenDeploy Admin interface is taking a long time.

Here's some information about the environment:
A solaris 10 environment
TeamSite 6.7.1, no service packs
OpenDeploy Base Server version: 6.1.1.0.0 Build 62302 Interwoven 20061128
Deployments can be fairly large: 5000 to 10000 files / deployment
Deployment is not transactional

Any ideas why this 'committing' phase takes a long time? It seems to take as long as the file transfer process.

I thought that maybe it was a transactional deployment and that a series of rewrites was taking place, but it's not transactional.

I also have a thought that, since we're writing into a TeamSite workarea, that perhaps the inherent 'misdirection' of writing into the TeamSite repository is a bit slower.

It is, also, a reverse deployment and I don't know if that has any bearing on the issue.

I'll hit the manuals to see if they've got some additional information on that phase of a deployment - but if any of you have run into this issue or just know offhand why this takes place, all help is appreciated!!

Wally Box
Nike, Inc.

Find more posts tagged with

Comments

Migrateduser

I see 19 views on this post, but no responses. Anyone have ideas? I've just opened a Support case about this also, but it seems that someone probably has run into this, or has some ideas...

Thanks for any help!

Wally Box
Nike, Inc.

nipper

just a guess are you using /iwmnt or /.iwmnt ? I am not certain if writes to the non-cached and cached mount points differ in speed (though reads certainly do)

Migrateduser

Nipper - thx for the thought. We just tried the swap to /.iwmnt from /iwmnt. No performance gain!

Migrateduser

An update and more info on this issue. I've been working with IW Support on various tests.

The issue seems to be that the receiver that we're pulling content from is located halfway across the country and behind a firewall.

The test that creates the problem consistently is to pull files with the reverse deployment into a TeamSite workarea (or into a non-TeamSite directory) that's populated with a good number (63K in this case) of files. It doesn't matter if we pull 2 files or 5000 files into this populated area - the commit phase takes about 20 minutes.

If we run the same test but pull the files into an empty directory, the commit phase is very fast - a few seconds.

So there's something in this commit phase where the local Base server is communicating with the remote Receiver server to assure that all files have been transferred and cleaned up correctly.

We're now looking into a way to minimize this commit phase communication. Ideas greatly appreciated!

Wally Box
Nike, Inc.

Adam Stoller

An update and more info on this issue. I've been working with IW Support on various tests.

The issue seems to be that the receiver that we're pulling content from is located halfway across the country and behind a firewall.

The test that creates the problem consistently is to pull files with the reverse deployment into a TeamSite workarea (or into a non-TeamSite directory) that's populated with a good number (63K in this case) of files. It doesn't matter if we pull 2 files or 5000 files into this populated area - the commit phase takes about 20 minutes.

If we run the same test but pull the files into an empty directory, the commit phase is very fast - a few seconds.

So there's something in this commit phase where the local Base server is communicating with the remote Receiver server to assure that all files have been transferred and cleaned up correctly.

We're now looking into a way to minimize this commit phase communication. Ideas greatly appreciated!

Wally Box
Nike, Inc.

Any time you have that many files within a single directory - you are going to be having timing problems because each time a new file is to be added, the entire directory cache has to be waded through. (for kicks - try this: /bin/time /bin/ls -F in a relatively empty directory, and in this directory with 65K files in it - and compare the results)

My general rule of thumb is that if you have more than 100 entries (files and/or sub-directories) in a directory - you should start thinking about how to split it up. If you have more than 500 entries in a directory - you should start acting on splitting it up. If you have more than 1000 entries in a directory you should stop whatever you've been procrastinating on - and split the **** directory up into a more reasonable / manageable structure.