nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Component Properties Window takes too much time to open

Tarp

My Content Authors are facing lot of problem in creating or modifying any pages.
A page consist of 12 component. Opening the Component Properties Window for each component takes around 2 minutes.After Applying/Saving the component Properties again take another 1.40 minutes.
So for modifying any single page it takes around 45 minutes for any content Author to modify the whole page.
Why it takes so much time in opening the component properties window?

Is there any way we can improve the performance ?

When I am performing in Network :
EDITING the component (Opening Component Properties Window) : 2 min
SAVING the component ( Applying Component Properties Window) : 1.40 min

Find more posts tagged with

Comments

vpatel

-- TS/SP version?
-- Are you going through a proxy? If yes, by-pass the proxy for a second and test it. I have seen proxies causing issues one too many times.

nipper

something is woefully wrong here. Taking 5 minutes is too long.

There are a number of things it *could* be, someone who understands (preferably the guys who wrote the components) need to debug this.

If you have a more recent version of TS/SP (6.7.2 or later) then you can go into the component guide and edit one of the OOTB components provided by IWOV. If that takes several minutes then you have a networking/hardware/config issue. If that opens quickly, there are issues with the components/pages/etc.

HTH

Andy

remove white space.rptdesign

Tarp

-- TS/SP version?
-- Are you going through a proxy? If yes, by-pass the proxy for a second and test it. I have seen proxies causing issues one too many times.

TS Version is : 6.7.1.1 SP2
SitePublisher : 3.0.2

We are not going though proxy.
What can I do to fix this issue?

Tarp

something is woefully wrong here. Taking 5 minutes is too long.

There are a number of things it *could* be, someone who understands (preferably the guys who wrote the components) need to debug this.

If you have a more recent version of TS/SP (6.7.2 or later) then you can go into the component guide and edit one of the OOTB components provided by IWOV. If that takes several minutes then you have a networking/hardware/config issue. If that opens quickly, there are issues with the components/pages/etc.

HTH

Andy

Andy I want to rectify the above figures as those activity were performed through CITRIX.

When I am performing in Network , without Citrix it takes:
EDITING the component (Opening Component Properties Window) : 2 min
SAVING the component ( Applying Component Properties Window) : 1.40 min

TS/SP Version detail :
TS Version is : 6.7.1.1 SP2
SitePublisher : 3.0.2

I tried creating a page with just one OOTB Component(LiveSite/Text Area) and I got following results:
EDITING the component (Opening Component Properties Window) : 1.58 min
SAVING the component ( Applying Component Properties Window) : 1.50 min

Its almost same results as my componets EDIT. So there is no problem in my component as such. So what might be the reason behind this slow performance.

Does it take 2 minutes for you as well to Edit a component ?
What should I do to increase the performance ?

remove white space_modified.rptdesign

nipper

OK, SP 3.0.2 was painfully slow, but not that slow. It also does not have the component guide so my previous suggestion will now help.

I have a customer on 3.0.2 and it takes 5-7 minutes to open a page with maybe 8-10 components. So that is less than a minute each (IMHO way too slow).

First look to see if you can upgrade. TS 6.7.2 SP3.1 is much better.

Second check your logs. Esp the servletd_out, it may be quite large and full of Java errors. Those may be a key to the issue

GRD

Andy, I have found that it's directly related to the number of physical objects in the site. On the dev server:

6700 objects = 3:27 for component window to open
2700 objects = 0:58 for component window to open
4 objects = 0:04 for component window to open

I am reaching out to the LS folks to see if there is a patch for this version. Upgrading is not an option for the next couple of months.

-Greg

nipper

Interesting. That makes zero sense, but it is interesting.

That should give tarp something to look at. If you hear a resolution, please post it.

vpatel

Andy, I have found that it's directly related to the number of physical objects in the site. On the dev server:

6700 objects = 3:27 for component window to open
2700 objects = 0:58 for component window to open
4 objects = 0:04 for component window to open

I am reaching out to the LS folks to see if there is a patch for this version. Upgrading is not an option for the next couple of months.

-Greg

What is your definition of an "object" when you say 6700 objects? Are you talking files/assets in the workarea?

Do you have non .page files under your "sites" directory? This has caused implementations to slow down quite a bit and it is against the best-practices / recommendations.

remove white space_modified.rptdesign

nipper

What is your definition of an "object" when you say 6700 objects? Are you talking files/assets in the workarea?

Do you have non .page files under your "sites" directory? This has caused implementations to slow down quite a bit and it is against the best-practices / recommendations.

Good point, I was on site and they do have non-page files inside the /sites folder.

vpatel

This has been addressed in the latter versions of LS but 3.0.2 this was a known issue. In any case, it is still a "best practice"/recommendation to not have any non .page file content under "sites"directory.

GRD

This has been addressed in the latter versions of LS but 3.0.2 this was a known issue. In any case, it is still a "best practice"/recommendation to not have any non .page file content under "sites"directory.

That would improve things, however, there are still about 2000 .page files. The client will probably have to live with it until they upgrade.

-Greg