Poor performance

[howie.lush@googlemail.com]

We recently upgraded to 7.5.1.31 currently running on 2003 SP 2 and
Sql 2005 sp1 (on a separate box) since the upgrade to 7.5 the
performance has died. RedDot runs really fast and then suddenly
freezes for all users. Looking through the logs it appears to me
mainly caused by the pagebuilder - when users are navigating SmartEdit
or previewing pages. Killing the dllhost.exe process immediately
allows all users to continue using RedDot normally, and gives an error
to the user that was trying to use SmartEdit or page preview.

Some of our projects are quite large, and we have followed RedDot's
advice of cleaning up pages with 200+ pages connected to one list and
removing overused keywords from old pages, so that no keyword is
assigned to more than 50 pages. While this has helped, the performance
is still worse than it ever has been in the past.

Spec of the boxes
cms - 4 x Xeon 2.8, 4GB ram, 100GB disk Database - 2 x Xeon 2.8, 3gb
ram, 100gb disk

Has anyone else experienced the problem of the page builder just
locking and freezing the server and if so how did you fix it?


Thanks,
Howie


- this message came from the Google Groups "RedDot CMS Users" group -

[Nick Wesselman]

We haven't had an issue w/ the page builder, but the Tasks button has
created performance issues for us recently when we went to 6.5SP4. Do
you have Tasks button refresh turned on? If so, try turning it off and
see if things speed up. Clicking the Tasks button will still be slow
though. RedDot is looking into the issue.


On Sep 18, 2:50 pm, "howie.l...@googlemail.com"
<howie.l...@googlemail.com> wrote:

[Samuel Williams]

We have exactly the same problem since upgrading from 7.1.1.8 to
7.5.0.48, but do not have a resolution yet.

We get a stack of COM+ Surrogate failures in the Event viewer
resulting from the PageBuilder. I'm told this basically means the
thing has had a catastrophic failure, and it's only Windows
intercepting it that is preventing the machine from blue-screening
completely.

We have a dual server setup, with one dedicated to publishing. It is
this publishing server that has the problems. We think it mainly
happens when multiple publishing jobs are running simultaneously - we
first noticed it in a big way when we had 4 going. When this is
happening, RedDot also slows to crawl: presumably because the process
is constantly crashing and being reloaded.

One thing I would recommend is installing RedDot using the user
account it will run under - not as local admin (which we were told).
It seems that running the install routine while logged in as any other
user doesn't seem to register the COM identities properly. This is
regardless of having Local Administrator permissions. I don't really
understand this: it's just what our infrastructure guy told me!

So far, the support guys in the UK have tried blaming various things,
but haven't come up with any answers. However, we're off to the
mythical RedDot HQ in Germany next week to discuss various things: and
this will be on the agenda...

Sam


On Sep 18, 8:50 pm, "howie.l...@googlemail.com"
<howie.l...@googlemail.com> wrote:

[cpayne]

We are also having performance issues with the page builder. The root
cause is that the Page Builder only processes one request at a time
(sequencial) so while it is processing pages for SmartEdit preview
performance issues and user time-outs are common. Especially when
user traffic starts inching towards 30 or more users. this is
especially noticeable if you use lots of Pre-execute code in your
templates.

This is a major issue for us, and the only way we are able to solve it
is by adding more servers in redirecting traffic accordingly..

We also noticed that the publishing jobs can get stuck in the and
require that the process be killed on the server. This happens if
individual pages are queued up for publishing and are stacked in
groups of 3 or more. This is a somewhat random issue, but has been an
issue on our publishing server since we upgraded to 7.1. (we are still
on 7.1 by the way)


I'm REALLY hoping that the page builder is part of the 8.0 rewrite,
and that it will be able to process multiple requests and be more
efficient.

Anyone know anything about the 8.0 release. Is the page building part
of the re-write?

On Sep 18, 1:50 pm, "howie.l...@googlemail.com"
<howie.l...@googlemail.com> wrote:

[Samuel Williams]

Hi Cory,

I saw a presentation on CMS 8.0 yesterday. It's almost a complete re-
write in C# .NET - including the PageBuilder. Scalability and
performance are two of the claimed benefits.

Sam


On 23 Sep, 21:10, "cory.pa...@gmail.com" <cory.pa...@gmail.com> wrote:

[BB]

We are running 7.0 and had a similar problem.

Try enabling 3gb support on the pagebuilder com object.

That should work.

-Brandon

On Sep 25, 9:05 am, Samuel Williams <samuel.willi...@reedexpo.co.uk>
wrote:

[Richard Hauer (5 Limes)]

The basic problem here is that requests through the IIS processing
pipeline are queued (i.e. single threaded) so even though the COM
objects are multi-threaded, or at least many are, they can't really be
utilised in this way through IIS.

To get around this problem there are a number of potential methods.
You probably don't want to start mucking with the IIS processing
pipeline in a packaged application like RedDot (though this may be a
viable alternative for a hand-turned web app) but there are some
easily tweaked IIS settings that could help.

For example, on the Application Pool's Performance tab there is a
setting called "Web Garden" that will allocate more than one
executable process (and therefore processing pipeline) to the
application pool allowing many more simultaneous requests. The down
side is that you will lose in-process session state because a single
user session will not automatically find the correct process (so it's
different than a load-balance scenario where sessions are "sticky").
In ASP.Net this is easily circumvented by switching to an alternative
session management method using the "sessionState" element in the
web.config file - I suggest using the "StateServer" mode which runs as
a windows service rather than the database, which is better if there
is more than one machine involved. There is no way of consolidating
the session state in "Classic ASP" across processes AFAIK without
custom session handlers.

You might also tweak some other settings in the web.config file like
the "processModel" element, which defaults "maxWorkerThreads" to 20
and "webGarden" to false. In this case the "webGarden" limits the
process to a single CPU rendering the quad Xeon majorly
underutilised. This kind of "webGarden" will still be able to use the
inProcess session state because it's only one process (albeit across
multiple CPUs).

Of course much of RedDot still uses ASP and not ASP.NET so some of
this info may be moot. I would suggest tweaking the Application Pool
settings in the first instance as well as adding more worker threads
to the web.config file to see if that helps.

P.S. I haven't tried any of this stuff with RedDot so remember what
you change in case it doesn't work! It should all work smoothly in
the ASP.NET version but we'll have to wait and see.

HTH.


Regards,
Richard Hauer
====================
5 Limes Pty Limited
www.5Limes.com.au


On Sep 26, 1:14 am, BB <baxl...@gmail.com> wrote:

[Leo]

Well things are better, we have isolated and fixed a problem with our
database server hardware, however we are still having to kill the page
builder dll 2 or 3 times a day. Embarrassingly it is usually clients
that spot it first so it just looks poor. Has anyone found and
implemented a fix that resolves the pagebuilder locking. As my wife
would say Reddot is Bloke software only able to do one thing at a
time !!

As Howie said at the beginning we did not have any of these issues
until we went up to 7.5.

Regards



Leo


- this message came from the Google Groups "RedDot CMS Users" group -

[Leo]

We applied a fix recommend by RedDot support, adding the following to
the rdserver.ini (<RedDot>/CMS/ASP folder):

[PUBLISHER]
xmlserver=0

Since making this change we have not had to kill dllhost.exe

The information from RedDot re this change is:

The publication process under normal circumstances utilises the page
cache via the xml-server. Under some circumstances this process can
run out of memory due to a limitation set by an associated Microsoft
technology. Setting xmlserver=0 however bypasses this limitation in
the process by changing the publication process to communicate
directly with the pagebuilder process instead.


Regards



Leo


- this message came from the Google Groups "RedDot CMS Users" group -

[El Pollo Loco]

There is no other way for RDCMS_Publisher to publish but to
communicate with RDCMS_PageBuilder.
XMLSERVER=0 does not do this.

XMLSERVER=0 actually just creates a new instance of PageBuilder
(dllhost.exe) for each publication which circumvents the memory
leak....



On Oct 15, 2:26 pm, Leo <leo...@googlemail.com> wrote:

[TheJonathan]

We've been having an increasing number of extremely huge dllhost
processes that takes out our CMS from time-to-time. It sounds like
this may help.

Has anyone else tried this out? Is it a safe enough change to make
without rebooting Reddot?

Cheers,
Jonathan


On Oct 15, 2:56 pm, El Pollo Loco <el.pollo.gord...@gmail.com> wrote:

[stpaul]

Does this change only improve publishing or does it also improve
overall CMS performance for SmartEdit users? We are having lots of
trouble with CMS performance in general, usually noticed first by
SmartEdit users. We are running 7.1.2.6.

On Oct 15, 2:56 pm, El Pollo Loco <el.pollo.gord...@gmail.com> wrote:

[El Pollo Loco]

You will need to reboot. There are too many DCOM, COM+, and Windows
Services to stop simultaneously to trust that the RDServer.ini setting
change will be active and sync'ed across all objects
etc........Rebooting is the cleanest way to yield a change in
RDServer.ini.

Also, under [PUBLISHER], you may want to try this one,
CHECKDEPENDENTPAGES=1

What this does is it tells CMS to not re-index related pages every
time a change is made to a page, and that there is no RE-indexing, but
just one query of the index at publish time. This will improve Smart
Edit significantly.....

On Oct 15, 3:48 pm, stpaul <pauljoeatkin...@gmail.com> wrote:

[Leo]

The main problem we were having was smartedit freezing for users.
Prior to the upgrade to 7.5 we had just one cms server and one
database server however after the upgrade performance was dreadful
hanging virtually every hour. We then put in a cluster one for
publishing and one for editing to ease the problem and along with
fixing a hardware fault on the database server, we reduced the hangs
to three of four times a day. Restarting dllhost.exe mainly on the
editing server but also on the publishing one brought it back to life,
however we would have to restart both servers every 5 or so days when
restarting the dll did not work. We also had to turn async tasks down
to four to avoid anyone starting more than four publishing jobs which
also locked the servers.

We applied the change to both (having to reboot them) last Tuesday and
have only restarted the dll once and that may have been unrelated and
have lifted async up to 7 with no problems.

Not saying this cures all ills we still have to boil the kettle to
make tea and coffee but for the first time in four weeks since
upgrading to 7.5 we are actually not having to babysit RedDot.

Regards



Leo


- this message came from the Google Groups "RedDot CMS Users" group -

[TheJonathan]

@Leo, we had to write a script on 7.5.0.42 to kill dllhost
automatically every 20 mins to try to save us when it goes rampant
during unsupported hours. It's brutal though.

Has anyone tried the latest hotfix 7.5.1.36? Does it help?

On Oct 15, 5:08 pm, Leo <leo...@googlemail.com> wrote: