bad scalability over number of flow targets
Hi!
I have a setup here where I have two workspaces. The second workspace "experimental" only flows to the first workspace "staging". The first workspace actually flows to the second workspace and to two other streams.
What I see is that some operations in the "staging" workspace take minutes, while those in the "experimental" workspace take seconds. (Disclaimer: I didn't benchmark this, but I claim to see a pattern). Note that one obvious reason is that after accepting a changeset into "staging", later accepting it into "experimental" is faster due to caching, but that doesn't explain all. For example, creating a changeset is slow in one workspace and fast in the other. Also, after creating the changeset, accepting it is fast in one direction and slow in the other.
Is this expected? Is this due to our (high-latency) network connection? Are there any remedies or workarounds?
Many thanks!
Uli
I have a setup here where I have two workspaces. The second workspace "experimental" only flows to the first workspace "staging". The first workspace actually flows to the second workspace and to two other streams.
What I see is that some operations in the "staging" workspace take minutes, while those in the "experimental" workspace take seconds. (Disclaimer: I didn't benchmark this, but I claim to see a pattern). Note that one obvious reason is that after accepting a changeset into "staging", later accepting it into "experimental" is faster due to caching, but that doesn't explain all. For example, creating a changeset is slow in one workspace and fast in the other. Also, after creating the changeset, accepting it is fast in one direction and slow in the other.
Is this expected? Is this due to our (high-latency) network connection? Are there any remedies or workarounds?
Many thanks!
Uli
One answer
I've never seen this kind of behavior.
The behavior that should be easiest to isolate would be the speed of creating a change set.
In particular, if you have a chance, try removing all flow targets from the staging workspace that is showing slow checkin behavior.
Then in a single Eclipse workspace, load a similarly sized component into the sandbox of the experimental and staging workspaces (a different component in each, to make Eclipse happy).
Then make a change to a file in each, and try a checkin ... do you see different performance?
Cheers,
Geoff
The behavior that should be easiest to isolate would be the speed of creating a change set.
In particular, if you have a chance, try removing all flow targets from the staging workspace that is showing slow checkin behavior.
Then in a single Eclipse workspace, load a similarly sized component into the sandbox of the experimental and staging workspaces (a different component in each, to make Eclipse happy).
Then make a change to a file in each, and try a checkin ... do you see different performance?
Cheers,
Geoff
Hi!
I have a setup here where I have two workspaces. The second workspace "experimental" only flows to the first workspace "staging". The first workspace actually flows to the second workspace and to two other streams.
What I see is that some operations in the "staging" workspace take minutes, while those in the "experimental" workspace take seconds. (Disclaimer: I didn't benchmark this, but I claim to see a pattern). Note that one obvious reason is that after accepting a changeset into "staging", later accepting it into "experimental" is faster due to caching, but that doesn't explain all. For example, creating a changeset is slow in one workspace and fast in the other. Also, after creating the changeset, accepting it is fast in one direction and slow in the other.
Is this expected? Is this due to our (high-latency) network connection? Are there any remedies or workarounds?
Many thanks!
Uli