How do you use Client Monitor

Stuart_Glasson

Hello Mibuso group,
I'm working with the NAV Server&Tools team in trying to re-build Client Monitor for the NAV Server/3 Tier, I'd like to understand how you use it today.

1) What type of tasks are you trying to solve when you use Client Monitor?
2) How often do you do it?
3) What are the limitations of Client Monitor and what could it do better?

If you prefer not to post a reply, you can email me at sglasson@microsoft.com, or you can catch me at Directions 2011 Berlin!

Thank you in advance to all who reply!

Stuart

MBerger

As a coder for our existing customers ( small customatizations and support ) i use the client monitor often for performance problems and finding out when a particular record is added/modified/deleted. The client monitor in itself isn't that useful, but the extended one ( the one that takes all the records the normal client monitor makes to to single lines ) is very useful.

For performance problems, the column "elapsed time" is of high importance, as is the columns with the filters used, used key and record found.
For the other problems, the sourceline from which the DB statement comes from as well as the type of database call ( insert/modify/delete etc. ) are needed.

The limitations are : the standard client monitor is nigh to unreadable, but that is solved with the extended one. Also, it would be nice if the client monitor would persist, even if the transaction is rolled back due to an error.

Off-topic : this ha sniothing to do with the client monitor itself, but it would be nice to have a "debug.print" command in NAV ( like in VB ) which will show the text you give it in a window during execution. At the moment, i have built soemthing like that myself using Excel.

mohana_cse06

1) Mainly Performance issues
2) When user complains of performance is low when calling a form or running report.
3) SQL Statement length is 250 only..when it is more than 250 it is truncating to 250 characters only

kriki

1) What type of tasks are you trying to solve when you use Client Monitor?
Very specific performance problems I cannot find with SQL Server Profiler. I generally start with SQL Server Profile and most of the time it gives me the info I need. If I really need to find which C/AL code is giving the problems, I use the Client Monitor

2) How often do you do it?
Not so often because it is too limited.

3) What are the limitations of Client Monitor and what could it do better?
-truncating of the SQL statement
-temptable limitations
-the 'extended' client monitor should be the default. It should NOT be necessary to import extra objects.
-There should be an extra column (or 2) in which the tablename (or table ID) is given and the second column is the company. The reason is that I am searching data for only 1 specific table and this would make it easier. (next point would be even better!)
-Filtering like in SQL Server profiler : Filter on duration (e.g. > 50 milliseconds to avoid too much useless data) ; filter on SPID or username (not needed now but if moved to the service tier it will be very useful)
-Saving data directly to a tab-separated file (I hate CSV. It always gives problems) (Avoid saving to a SQL Server table for performance reasons!).
-Possibility to save the SELECT with the real values used for the parameters or an extra field with all the parameters in it. E.g.
-- select * from dbo.[Cronus$Item] where [Item Category Code] = 'ABC' and [Product Group] = 'XYZ'
-- select * from dbo.[Cronus$Item] where [Item Category Code] = '%1' and [Product Group] = '%2' and in the second column '%1=ABC,%2=XYZ
-BLOB in which is stored the Actual Execution Plan from SQL (On request with some setup)
-possibility to monitor another session than the current one

PeterD

1)
Performance issues

2)
Now only as a last resort
The current client monitor isn't very easy to use. If I set a filter on i.e. Parameter = Records Read and Number > 10000 it shows me the lines which might need attention. The trouble is that you don't see the context like Key and Filter. So I try to solve that by replacing the filters with a filter on Entry No. for all found lines. That is a pain in the ...

3)
If all information is presented on 1 line it is easier to filter and see results in context. I imagine that al information on 1 line means a very long line and scrolling back and forth to see all information. So a card view with all information of 1 line might be useful.

===

@MBerger
Where did you get the extended client monitor?

MBerger

PeterD wrote:

@MBerger
Where did you get the extended client monitor?

i found it somewhere on a navision tools CD in the past. Just had a look, and i can find it here in :
- Navision NL3.70 Tools\Implementation\Performance Troubleshooting Guide\Client Monitor.fob
- Navision W14.00 Tools CD update 1\Implementation\Performance Troubleshooting Guide\Client Monitor.fob

[edit] Seems i can't attach a file to a post, so i will pm you the fob

Miklos_Hollender

One important use is figuring out how exactly different C/AL commands are mapped to SQL Statements - what is the actual difference between FIND('-') and FINDSET etc.

Another is finding performance bottlenecks either per table per index or per code running.

I use the extended client monitor objects which denormalizes the results and then copy everything over 0ms into Excel and then make a pivot table either per table or per object summing up the times elapsed and then work my way into more details by adding more columns into the pivot table.

At some projects, never, at some projects, pretty much weekly.

The most important limitation is that it only works for performance bottlenecks that can be replicated i.e. if a user says this thing is always slow I can try that with CM but if users simply experience "whitescreens" for minutes only sometimes and don't know for what reasons and in what circumstances then I canot use the CM only the SQL Server tools. Which are good but do not say what line of C/AL code is running - big problem!

Basically if you could just make it so that to log the C/AL code running into a physical, SQL table for each user, like, username, company, datetime, code, a table like that, then we could match that with the SQL Server tools like analysing these advanced system views for managing performance and JOINing them with this table by say datetime, we could figure out what line of code running caused the problems.

kine

1) Finding point where in code is modified/inserted/deleted some record in specific table (e.g. when solving problem of "another user modified..." when I am in collision with myself - nested modifications of same record). Performance problem, locking orders, finding commits in the process (when posting on the fly in some more complex process), solving different errors where the reason is not clear.
2) Once per month
3) already written

David_Singleton

I can't believe no one has mentioned the BIGGEST problem with Client Monitor.

LICENSE.

Its a real PITA when the client has a problem, and you need to use a developer license to do this. Of course it can be done, but I can give a specific example. I have a client that have an intermittent performance issue, clearly it depends on the current data they are working with plus what other users are doing, it would be great i as soon as they see they are having the performance issue, if they can just turn on client monitor and run it. But they have to call me we need to set up the remote connectivity, etc, etc.

There are many more cases, but that's just a particular one that happened recently.

Then there is the issue where the customer does something with a developer license, and it does something different, due to permissions. Especially considering this is often done at posting time its not a good thing for a client to be working on their live system with a developer license.

I just can't see why its not a part of a customer license.

David_Singleton

The second thing (and I mentioned this to the team in Denmark in February).

Its a bit crazy to have all these separate tools.

Ideally, client monitor, debugger, Bench Mark Tool kit, code coverage etc should all be integrated into one "product".

David_Singleton

Third thing is remote support.

I would like a much easier way to get the data from the customers machine to my local copy of their database. So I can take it off line. The excel export (as mentioned above) is never ideal, and better is some simple way to get the data back into my local DB where I can work with it in Navision.

DenSter

The client monitor itself is such a resource hog that it causes performance problems itself, so letting it run during the day is not an option. As a result, you often miss the 'real' problem because those are usually caused by a confluence of multiple processes at the same time.

For me SQL Profiler is much more useful because I can set some filters and let it run all day. When a user then sends me a screenshot at 10:34, I can scroll through to 10:34 and see what was going on at that time. The only thing missing from SQL Profiler is the link to the NAV object, but usually it's not too difficult to figure that out.

I use client monitor only when after using SQL Profiler I have not been able to link the query to C/AL code. Ideally I would want to be ale to let the extended client monitor run on a particular user's box all day, and log their activities.

What would be great is if we had a client monitor that has the same small footprint as the SQL Profiler (meaning it does not cause massive performance itself), that we can let run all day, and that can be saved in a file for later analysis.

And by the way, I fully agree with David that the extended client monitor should be included in EVERY license, because many customers do not allow the developer license to be loaded into production, nor should they. You should not need a developer license to be able to run this tool. And I also agree that these types of tools should be bundled together. And I also agree that these 'extended' tools should be part of the base product.

So in short: just give us everything, with a free license

DenSter

one more thing: I also agree that the standard client monitor is not user friendly at all, and it is limited to the active session (i.e. you lose the data when the session is closed). The extended client monitor should be the standard one, with options to save the data in a table or in a file, similar to how that works in perfmon and SQL Profiler.

Belias

Now, client monitor does not log the activities of the role tailored client (we all know that businness logic is executed on the server).
For new customers that wants an RTC client, we certainly don't develop a classic UI, with classic reports and forms -> this means that we can't use client monitor on RTC installations without creating testing objects.
Wouldn't it be great to have a client monitor on the RTC, with a fancy page-like UI?