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

Teamsite performance analysis

RonaldV

Hi,

does anybody have any experience with finding performance bottlenecks in teamsite?

It should consider:
- server (memory usage, cpu usage disk throughput)
- network
- client (html & javascript rendering)

It should also be able to rung&log for a longer period and then pinpoint the bottlenecks because in my experience teamsite performance tends to vary over time (e.g very slow 1 moment and 3 seconds later no problem :-)

My actual problem is on windows but I am also interested in unix-solutions.

Any hints, tools, tips...?

Find more posts tagged with

Comments

RonaldV

Nobody??? .

Bhargav Coca

If people start replying this post there will tons of bootlenecks in every aspect you have mentioned.

Ideally (If there is ever any system like this)
if you have top of the line hardware on Solaris or Linux Platform
With fast network speeds. Majority of bottlenecks pertaining to CCPro UI will be minimal. (Provided you be cautious when updating patches for OS).

The bottlenecks usually raise because of our coding skills. If you have a code which does the exact functionality as required in minimal possible lines with acceptable logging patterns will always win. Else ther will always be issues in the way you logfiles get generated, you external tasks behave you deployments taking usual than longer time to deploy so on and so forth.

Its hard to pin point bottlenecks on a case by case basis.

HTH

Rick Poulin

If you have a code which does the exact functionality as required in minimal possible lines with acceptable logging patterns will always win.

Pretty sure I can easily come up with example situations where more lines leads to better performance, esp in Java Smiley Tongue

But yeah, I agree with lilleywhite. If the bottleneck is in the iwui, then custom code is usually to blame. Tweaking iwov itself is only ever really useful if the iwserver is the process that's bogging down. The only exception is perhaps allocating additional memory to the app container. More often than not, reviewing your Java code and turning off unnecessary logging (provided you used Log4j or similar) is where effort leads to faster/better dividends.

As for client-side, well, I'm sure it's not news to you that Iwov is a beast with that. Nothing short of up-to-date browsers and half-decent client machines is going to help you there.

Bhargav Coca

Yes, I stand corrected, I should say Optimal Lines of code which improves functionality.