Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

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

0 votes



One answer

Permanent link
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

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

0 votes

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details

Question asked: May 24 '12, 8:24 a.m.

Question was seen: 2,667 times

Last updated: May 24 '12, 8:24 a.m.

Confirmation Cancel Confirm