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; } } }

Slow loading DCRs

Mr_Cruise

Env : TS 6.5 on Solaris

We have just moved our TeamSite server from the UK to the US and the business users are still in the UK. DCRs are now taking too long(from a business perspective that is) to load. I know the issue is related to the network but this will take time to fix.

I remember that you can tweak TeamSite to cache more aspects of the DCT GUI, but I cannot find the article.

Can someone please point me in the right direction ?

Thanks in advance.

Find more posts tagged with

Comments

jkm

Did you try mod_expires within iw-webd ? This works pretty well for network latency issues for remote locations. I have done this on TS6.1 where after setting the mod_expires attribute in httpd.conf, it solved the load issue upto some extent.

There are bunch of articles related to this on support site as well. You can find them if you do a quick search.

prem_pratick

Hi , As stated above Pls try the below URL

http://devnet.interwoven.com/site.fcgi/techlib/053439

We also Upgraded from TS 5.52 to TS6.1 We also Faced the performance issues.

Then we Opted for mod_expires ,

In the absence of caching headers such as those set by mod_expires, most browsers will query the webserver for each component (e.g. images, .js, and .css files) of each page it's rendering to see if it's changed since it was last transferred. If the file has not changed on the webserver, the webserver will return HTTP 304 -- meaning that the object in the browser's cache is recent enough. If the file has changed, the new version of the file will be downloaded.

Though the process of a browser checking to see if there's a new version of a file doesn't involve much data being transferred, it's still a hit to the web server and still suffers from network latency. It's especially problematic when there are a large number of page components per page as there are in the rich UIs of Content Center. However, in the case of ContentCenter, we know that the static images rarely change. Based on this knowledge, we can reduce the number of hits to check for updated content and improve performance by sending an expires header set a short time (2 hours or so) into the future. This will mean that the browser will use the version of the file in its cache without asking the web server if it's changed for 2 hours, which small as it may seem, is enough to result in a noticable improvement in UI performance to the end user, especially end users on high-latency connections.

Hope so this Helps.

Prem

jkm

Hi All,

We are just moved to TS 6.7.2 and we are getting some serious issues with file browser window performance.

Actually one of our content directory has near to 4500+ files and when we click on Save button on DCR then it tries to load all the 4500+ first and then user can give the name for the DCR to save.

To load 4500+ DCRs, take huge amount of time on TS 6.7.2 but compared to this on TS 5.5, when user click on save button then it does not load all the DCRs and user can save it very quickly.

I would like to know few things

1) Is there a way where we can set not to load 4500+ files in save window as in TS 5.5 and user can just add file name itself?

2) Is it possible to load only 100 files instead of load all the files together?

3) mod_expire, will this cache the browser window content as well? Just want to know the opionions before we start exploring it more on our test server

In the current state, our users are feeling that 5.5 was better than 6.7.2!!!!

So looking for some ideas to resolve this problem

Adam Stoller

Personally, my feeling is that anyone who puts 4500+ files within a single directory deserves to get slow performance.

I don't remember if 5.5. tried to show the contents of the directory where you were saving the DCR or output file - if not, then that would explain the perceived slowness - and perhaps you can file a FR with Support to provide an option not to show he contents of the directory when saving a DCR or output file.

Again, however, I think this is more a failure of implementation design than product design. If you use auto-naming functionality (either built-in or customized) for the DCR and programmatically name the output files based on the name and data-relative-path of the DCR (i.e.: do not dump everything directly in data/) - then your users will never see the list of files and the process will probably go a lot faster.

Jamik

Personally, my feeling is that anyone who puts 4500+ files within a single directory deserves to get slow performance.

I don't remember if 5.5. tried to show the contents of the directory where you were saving the DCR or output file - if not, then that would explain the perceived slowness - and perhaps you can file a FR with Support to provide an option not to show he contents of the directory when saving a DCR or output file.

Again, however, I think this is more a failure of implementation design than product design. If you use auto-naming functionality (either built-in or customized) for the DCR and programmatically name the output files based on the name and data-relative-path of the DCR (i.e.: do not dump everything directly in data/) - then your users will never see the list of files and the process will probably go a lot faster.

definitely agree it's a failure of implementation. heck even windows explorer takes a long time to load when dealing with that many files. I wouldn't expect fast performance with that many files in one directory.

jkm

Agree with you Adams, if users are not structuring content in right manner then they should deserve it but they are using system for long now and migration of content into logical structure itself can be a decent size exercise.

IWOV auto naming function does not produce user friendly names but a simple custom code can solve this problem. We are already working on this option.

I was wondering if there is an easy option available which is just a matter of adding some thing to ui_custom.xml to avoid loading 4500 files and it will load only 100 files itself

Something like

[HTML]

[/HTML]

Adam Stoller

...
I was wondering if there is an easy option available which is just a matter of adding some thing to ui_custom.xml to avoid loading 4500 files and it will load only 100 files itself

Something like

[HTML]

[/HTML]

I'm not aware of any such option, though that doesn't mean one doesn't exist.

I suggest you contact Support as this is the kind of thing which they should either be able to point you towards a setting, or something which should get filed as an FR that will hopefully be taken into account while they work on the next version of the UI (this is likely a piece that might have been missed when they worked on the ContentCenter UI as it kind of falls between the cracks of what is TeamSite and what is FormsPublisher)

However - all that being said - fixing the implementation is the "right" thing to do even though it may require a short-term hit to do so.

Good luck

printout window.JPG