reduce publishing time

[Jo]

Hi,

We are publishing less than 100 pages every week and it takes more
than half an hour to publish. We don't do a full publish, but only two
section in navigation. We have some archive pages. Every week when we
create new pages, the old pages will be moved to archive section. We
have got a script to use for editors to do that. Once it is moved,
when publish the archive it will publish all the archived pages,
regrdless of the newly archived ones.

- can we avoid publishing all pages instead only the new ones ?
How can we optimise it?

We are using navigation manager. CMS Version 9.0.0.27

Please share your ideas how achieve less publishing time.

Many Thanks,
Jo

[markus giesen]

Have a look at the publishing settings to make sure you don't publish
all files every time.
Also check for PreExecute code within the templates, this can slow
down publishing a lot.

Version 9 should make use of the .NET publisher which is usually
faster than the old ASP based solution.

[Jo]

Thanks for the reply. I have selected not to publish all the related
and following pages.
But since it is on navigation, all the pages under the navigation link
be published even if we need to publish only one pages.
Can we avoid publishing again all the pages in the navigation ?

Thanks,
Jo

[kimdezen]

Hi Jo

What Markus was referring to was the actual Publication Settings for
the project.. (rather than the settings in the actual publish page
dialog)

SmartTree > Start > Administer Publication > Project - and under the
Action Menu select 'general settings'

Just make see that the checkboxes 'always replace pages' and 'always
replace media files' are unselected.

Each time a publication is kicked off, the CMS will only republish
those pages that have changed - which should cut down the publication
times.

Kim

[Jo]

Thanks kim,

Those are all already unselected. But I have selected the options
Clear page builder cache before publication , No warnings in e-mail or
publisher report,
and No warning that the page will not be published in this variant .
Now the publishing time is better. But I am monitorng ...

Thanks,
Jo

[PaulG]

I would generally recommend leaving the "Clear page builder cache
before publication" option unselected as it can be time consuming
process (and occassionaly problematic, especially on larger projects).

To be honest, 0.5hr to publish ~100 pages isn't necessarily that
unusual. The publishing time can depend on a number of factors like:
- complexity of templates/pages (nesting/linking of containers/lists/
navigation, pre-executing code, etc)
- load on CMS server (e.g. if other publishing or async jobs are
running)
- publishing targets (e.g. quantity and destination such as local
publish vs. ftp over internet where connection speeds come into play)
- variants (number of language/project variants)

Paul.

> > > > > Jo- Hide quoted text -
>
> - Show quoted text -

[Jo]

Hi Paul,

Thank you for your thoughts.

I completely agree with you that ~100 pages may take .5hr to publish
if the factors behind it are complex.
But our is a very small intranet site. Agree that we have got some pre-
execute code and navigation.
But I do have to say none of those are complex. And we haven't got any
asynchronous scheduled jobs
running during the publication time.
We are publishing to delivery server. There also no other process
going on during publishing pages.
We normally publish off peak times.

Anyway last publication hadn't taken much time less than 3 minutes
once I made the changes to the project settings.!!
But still I am not convinced, so waiting for the next publication next
week.

Thanks,
Jo

[markus giesen]

On the Deliver Server side the content might be within a couple of
minutes but then it takes some time to actually get Delivery Server to
import the new content.
Are you delivering all your HTML and asset files using Delivery
Server?
It might be better delivering assets and CSS,JS via IIS and only let
Delivery Server handle personalisation and search (via verity or
whatever you might use)

[Danny Baggs]

I'd agree with Markus' point here and would personally push this as being 'best-practice'.  Delivery Server is a strong tool for personalisation and integration.  If content doesn't need controlling (security), personalisation, or integration then it makes sense to deliver this statically outside of Delivery Server.

This is typically what happens to images, css, and js files.  By doing this, you then take advantage of IIS or Apache's HTTP Server's ability to encourage browser caching, improving page load times for your users.

If you would like more information then I would encourage reading my blog post where I go into a little more detail: http://bit.ly/ad3oai.

Regards,

Dan

--
You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group.
To post to this group, send email to reddot-c...@googlegroups.com.
To unsubscribe from this group, send email to reddot-cms-use...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en.