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 Performance in popups

code

Hello,

I'm running TS 5.5.2 on W2k.
In general the overall working with the CMS is quite ok. However, some editors complain about bad reponse times when they try to call "File-> New data record" or have to work with the FileDialog (HTML).

The performance in the standard directory structure is pretty good. So, I'm wondering what might slow down the system in this particular case.

It would be great if somebody has a suggestion what I may analze.

Cheers.

Find more posts tagged with

Comments

Migrateduser

My experience is that usually these kinds of performance issues are related to the browser (specifically the new window operation which Interwoven seems to love takes about 6 seconds in some versions of IE in some (unknown) configurations), not the server. I think once it seemed like It MAY have been related to proxy configuration - one machine configured for no proxy would respond almost instantaneously, another configured for the proxy was very slow. Unfortunately I am not sure what the solution is.

Can you log on to the server, configure the browser for no proxy and see what the performance is? If it is OK that would confirm it's the network/client.

nipper

Do you use formapi or inline callouts ?

One place to look if so,

Andy

code

This was the right hint.
There are two inline commands calling a IPL file. On the hand they are pretty straight-forward without too much application logic. However, If I remove them, the reponse times are a lot faster. I decided to open a case for this anyway, because the perl code is absolutely necessary.

Thanks for your comments.

Adam Stoller

If the perl code is not written efficiently - you'll pay for it in performance.

However, the best thing would be able to use a persistent Perl engine (like mod_perl and/or speedycgi) so that you don't have to pay the start-up cost for invoking a Perl process each time you edit a DCR.

Unfortunately the above would fall under customization, as the persistent Perl engines are not (I believe) platform independent, and they require you to modify your Perl code somewhat to work with them [* if your perl code is not well written to begin with - more significant modifications will be necessary]

Note: I, personally, have not had a chance to try this kind of thing out - I've wanted to, but haven't had the time or the environment in which to do so. Thus I am unable to provide specifics / how-to's. Sorry

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com