Performance Monitoring 2

[SQJ]

We are looking to run a series of Performance Test on the Livelink application.

Are there any recommendations as to the best Perfmon counters to monitor for
a) Web Server
b) Application Server
c) Database Server

Unless there is another performance monitoring tool that is bundled with the Livelink application ?

Regards

Steve

 

[appnair]

Livelink performance,how it fares particularly well on all apsects,web,db is usually analyzed by using lightweight timings logs.Each thread of the livelink server usually three not more than five will produce a log on startup of the server.This can be analysed by buying opentext's own performance analyzer or by writing your own program,.OT Perf analyzer can do more than just timings logs.However it does measure only when a registerd request hits your livelink server,so you might have to look at it with conjunction with web server logs.the microsoft log parser for IIS is quite useful and simple.I have used it.

If you do not know how to set up timings logs search for the same in the opentext KB.Usually it is done by inserting aline called

WantSummaryTimings=TRUE in the [options] section of your opentext.ini file and re-starting the server.Interpretation of the various fields are best understood by perusing the discussion area in OT for that.

Hope this helps




Well, if I called the wrong number, why did you answer the phone?
James Thurber, New Yorker cartoon caption, June 5, 1937

 

[ggriffit]

You can also use the Monitoring Agent which will give you end to end times for that request.

The Performance Analyser which gives you the details of what is happening once the requests reach Livelink so you can see concurrent usage which often has a bearing.

These coupled with a stress test tool, such as the free MS one should give you some useful information.

However, you will also need to bear in mind the following :

1. Performance is relative to what else is happening, if your network is 95% busy then LL may be percieved to be 'slow' even if it is not, so you need to understand your environment.

2. The figures you get back are relative, is 5 seconds slow for a function return ? for a login to a 100 user system probably, for a complex search with permissions over 1000s of doc probably not, so you must understand the context.

OpenText do offer a Performance Review offering where they will come in and do all this for you and then give you the results, these are often worth doing and you get lots of info out of them and they can be used for comparison later on and setting benchmarks.

Greg Griffiths
Livelink Certified Developer & ECM Global Star Champion 2005

http://www.greggriffiths.org/livelink/

 

[davidt50]

Some other points to consider:

- If you have over 60-70% constant Livelink thread usage then you are getting into thread saturation and need to reconsider your load requirements.
- The previous point reflects on the RDB as well, if the system is designed to handle 100 concurrent users and the threads are maxed on a consistant basis, there is a good chance the RDB is loaded as well.
- As Greg mentioned partially already, network latency will play a significant part in sending the finished pages to the end-user. The server may take only 0.8-1.5 secs for a given request, but may take 2-5secs to send the page across the wire. The LLMA ( Monitoring Agent ) set up at different locations ( with different latencies ), within the organization can help track and assess user performance.
- In at least 951 the following setting should be used:
[Client]
ReceiveBeforeSend=TRUE

This will help release the thread as early as possible, in 97 (not 100% sure about other versions) that means the thread will not wait for the page to be returned to the user.

 

[DrDDT]

I'm measuring the time it takes for our monitortoring tool
to finish a basic livelink test.
My test does a login, browse and search.

The absolute value of the test time returned is of no use, but comparing the returned time over a period of time
gives a good insight in system use and relative response times.