I had a similar situation after checking "always replace media files" in the Publications Settings dialog.
Publication works like this (roughly): 1. RedDot writes everything out to /RedDotTemp directory (the job moves from an 'active' job - to completed in the publication log section at this point) 2. Directory or FTP transfer takes place The publication report gets 'drafted' and then rewritten as the FTP process occurs. It sounds like the FTP process is hogging the connection - and it's a linear process - so while your publishing is multi-threaded, your FTP process will queue up like a soup line. If you're republishing all your media files - that can produce a much longer publish. I'd have a look at that particular setting in the Administer Publication > Project > (action menu) Edit General Settings > 6th item in that list (Always replace media files). Uncheck that if you're trying to reduce the publish time of your project. You may need to check that box to ensure everything is flushed out once a week, but if you're getting great delays - have a look at that section. Wayne's suggestion below is a good workaround for the long term - and a better setup in general. Luck, .dave On 28-Aug-09, at 9:26 AM , Wayne Bouwmeester wrote: > > I guess this may seem like an obvious question, but have your network > folks changed anything that may be slowing down the connection to the > FTP server around the same time you noticed the significant slowdown? > > Something to think about: > As a test, I'd create a publishing target to the file server, try a > full publish to it, then again the next night (the times may differ > depending on your settings) > If you get way better response publishing to the file server (I'm > guessing you will), I'd look into implementing a product that can push > the files out from the file server to ftp server. We always see faster > publishing to a file server target, and then you can use best of breed > software to move the files after the publish / keep them in sync > during the day. One of my clients used winscp and it worked fairly > well. I haven't done a lot of research into other tools. > > NB - I'm not sure how much better CMS 10 is for FTP vs file server - > it may have made great gains. > > Wayne. > > > On Aug 28, 7:47 am, rwagner <[email protected]> wrote: >> I want to throw this out to the big brains out there. >> >> We have a CMS nightly publication that is 6000+ pages and we expect >> to >> take about three hours to publish to LiveServer. Lately, it's been >> taking in excess of 12 hours, and sometimes we have to shut the job >> down because it prevents publications from taking place the next day. >> >> The publication report in the CMS says "finished" but only displays >> the media files published, no pages. After that it takes hours and >> hours before an email gets send and the rest of the pub report fills >> out. During this interval there is an async process called "FTP- >> Transfer for PROJECT NAME" that sits in the async queue and does not >> permit any other publication jobs to pass through. >> >> Has anyone out there seen something like this? If so, any ideas on >> what might be causing it or how to approach fixing it? >> >> Much thanks for any help. >> >> -rw > > -- daveb --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en -~----------~----~----~----~------~----~------~--~---
