Tips for reading trace files?

[atostaine]

Our VL-WIN Framework application takes 2-3 minutes to load over VPN. It works fine locally. We are trying to find the component that is causing the delay but reading the trace with 370K lines, even on trace level 1, is difficult to say the least.

Has anyone done anything cool like eliminating the LANSA component lines, finding large time differences between entries, etc?

Thanks, Art

[Tim McEntee]

Hi Art

370,000 lines of VLF tracing is a lot of activity to be happening for a start up. But this tracing should mostly be local, generated by the client program so will not really be affected by a slow VPN.

One thing that will slow down a VLF-WIN system is repeated calls to the server. Inside your client code are there many fetches and selects? You should consider batching up as much of (or all) of your I/O into call_server functions. The many database reads are performed in one hit on the server without any interaction with the client. The toing and froing between client and server would then be minimized where each of these interactions takes time. On a fast connection you don't notice it, but on a slow connection each one takes longer and it all adds up.

The other thing that might slow the system is the amount of data being transferred.

To test where you are having issues you could put times between calls on your client side and server side.

In your client
#STRGO1TIM := #STRGO1TIM.now
use bif call_server_function ...

(or this could be a bunch of IO)

#ENDGO1TIM := #ENDGO1TIM.now

#TIMEDIFFG1 += (#ENDGO1TIM.AsNumber( CCYYDDMMHHMMSS ) + (#ENDGO1TIM.FractionalSeconds / 1000000000)) - (#STRGO1TIM.AsNumber( CCYYDDMMHHMMSS ) + (#STRGO1TIM.FractionalSeconds / 1000000000))

Inside your function do the same with different variables and exchange them back.

calculate the time difference for the the outside of the calls and the inside of the function and the difference of those two values will be how much time is taken in travelling back and forth between the client and the server.

If your I/O is mostly written on the client side then use lots of these variable on the client to see how time is progessing.

Tim

[atostaine]

Thanks Tim. A long wonderful time ago Hamad have a session at a really cool Lansa conference how you don’t alway have to do a call_server_function.

We’ve mostly been using that advice. But on VPN we found that loading a drop down of batch numbers that were open only was reading every batch number detail , resulting in 10/100k plus reads.

It would have been helpful if the logging function could eliminate lansa entries.

[atostaine]

Thanks Tim. A long wonderful time ago Hamad gave a session at a really cool Lansa conference how you don’t alway have to do a call_server_function.

We’ve mostly been using that advice. But on VPN we found that loading a drop down of batch numbers that were open only was reading every batch number detail , resulting in 10/100k plus reads.

It would have been helpful if the logging function could eliminate lansa entries.