deployments are queued up, dont deploy for a long time

I have a box where there is a 45+ min wait between when i request a deployment and when it actually goes out.

can anyone give any suggestions on how to speed up response times?

(i dont use -inst in the iwodcmd)

Find more posts tagged with

Comments

kaalraa

I have a box where there is a 45+ min wait between when i request a deployment and when it actually goes out.

can anyone give any suggestions on how to speed up response times?

(i dont use -inst in the iwodcmd)

i dont use -inst in the iwodcmd is the only issue. When there is a instance of deployment running, then the same instance is not being queued up till the time the earlier deployment comes to an end.

To make up with response time, i strongly recommend to use -inst attribute.

nipper

We cannot tell for because of the lack of information. This could be a lot of stuff. However, since you bring it up, why aren't you using -inst ? If a deployment is already running, then the new one will queue up waiting for the previous to complete.

This can also happen if you are using a date different deployment and not using a filelist. It needs to compare every file on each side.

Post some logs and maybe someone can help/

kaalraa

We cannot tell for because of the lack of information. This could be a lot of stuff. However, since you bring it up, why aren't you using -inst ? If a deployment is already running, then the new one will queue up waiting for the previous to complete.

This can also happen if you are using a date different deployment and not using a filelist. It needs to compare every file on each side.

Post some logs and maybe someone can help/

In my case, where i have not used -inst... it is not queueing up the new job. Could you please confirm, if its getting queued up correctly on your side?

Just want to make sure, if i have any other issue on those job types. Smiley Happy

koryakm

Thanks for the quick replies! (faster then my deployment which is still queued)

i was under the impression that i need to install opendeploy to another location to be able to use the -inst in the deployment. is this incorrect?

what is a "date different deployment", is that different from deploying everything in the "data" dir?

nipper

Thanks for the quick replies! (faster then my deployment which is still queued)

i was under the impression that i need to install opendeploy to another location to be able to use the -inst in the deployment. is this incorrect?

what is a "date different deployment", is that different from deploying everything in the "data" dir?

These questions show why your deployments are taking so long.

No, the -inst switch is meant to have multiple deployments goign to the same target, in parallel.

Your question 2 is maybe. If you deploy everything in the data dir then OD will likely compare the date on every file and deploy only those that have changed. This is a long and slow process.

Most deployments are done with a filelist. You generate a file with a list of files to be deployed. OD pushes those files out and nothing else. If you do a deployment as part of a workflow, then this is by far the best way to go.

koryakm

thanks.

I will try this inst thing and see how it works for me.

thank you.

Adam Stoller

A couple of clarifications:

enabled.For other situations - you should consider what the behavior will be and whether or not you wish to enable either or both of the above options.

sumitk

Along with Ghoti's suggestions ... one more suggestion from my side .. might be usefule for you.

Try to increase the buffer size of the data being sent to receiver in odbase.xml.

..

See if that helps.

Cheers,
Sumit

sumitk

forgot to mention xml :

sumitk

transportProperties name="od" bufferSize="8000"