It appears deployments are not longer threaded as they were in Otto v3. I believe this is part of the atomic fallback feature. But is there anything to make this faster.
I have two deployments defined for each server:
- UIs (Replace)
- DATA/DOCS (Migrate)
With Otto v3 the UI deployment was fast. For my UI updates I believe I had the continuous file setting at 5 and it ripped through the deployment of 20 files. (Also, I am doing this process for 13 servers.)
With OttoFMS it is painfully slow. Here is one in progress:
Here is it completed:
I would understand the time difference if each UI file was pulled for each replacement (as it was in Otto v3) but the build is already the server. It looks like it is just waiting for each open process to complete before moving on.
FYI - with Otto v3 I had DATA/DOC migrations set to only 2 files congruent.
It this something that may be improved?
Jeff
Hi Jeff,
We turned off concurrency in OttoFMS as it caused a lot of problems for people who did not have big enough servers to handle it. People were setting it to 20 and it would suck all the memory on the machine.
But we have already have a request to add it back and we are going to.
OttoFMS is smart enough to know that the build is already on the server, and it will only fetch it once. So between the concurrency being back and OttoFMS optimized fetch handling it should be better than it was in Otto v3.
Thanks
Todd
1 Like
I can see the concurrency has been added to v1.10. But I’m not sure it’s what I need.
Given the case of 25 UI files on a single server. These are all the same file with different names (REPLACE). The deployment is defined with 25 sub-deployments.
I see the concurrency assignment on each sub-deployment. But I need it at the main development level.
If each sub-deployment contained more than one file, then the sub-deployment setting it useful.
But wouldn’t it be easier to simply assign the concurrency level at the main to be applied to each sub?
Jeff
Ah yes… I get it now. FileMapping is done at the sub-deployment level. So you need sub deployments.
Ok we are either going to let you choose a source file many times in a sub deployment, so you could put all 25 files in one Sub-deployment
Or we are going to have give an option to on the fly merge the sub-deployments together. So it is treated as one and can use the concurrency across all the files
I get it now. We’ll see what we can do?
Thanks
Todd
1 Like
Please give us the option to use 1 source file multiple times in 1 subdeployment. 
Edit: Second option as an additional feature would be excellent as well 
