LoadRunner: Compilation and Runtime - 2
Submitted by Suresh Nageswaran on Tue, 18/01/2005 - 07:28.
Mercury LoadRunner | performance testing
So now that we have a little more insight into the compilation process, let's look at what we start with and what we end with. To do this, like I mentioned earlier, we need Dep Walk.
Dependency Walker 2.0 comes with a rather nifty feature called Application Profiling. This is a technique used to watch a running application to see what modules it loads. Dynamically loaded modules that are not necessarily reported in any on the import tables of other modules can be detected this way.
We start with a barebones script - one having exactly one action with maybe an lr_output_message() and invoke MDRV on it for only the compilation. Initially the script has only the following files: vuser_init.c, Action.c, vuser_end.c, default.cfg, default.usp, BareScript.usr.
The command-line arguments look like this:
mdrv.exe -usr BareScript.usr -compile_only
Application profiling on this automatically causes invocation of cpp.exe. The command-line options passed to CPP.EXE are captured by the App Profiler. Here's what it looks like:
Program Executable: c:\loadrunner\bin\CPP.EXE
Program Arguments: -f"c:\projects\loadrunner\barescript\options.txt"
MDRV has created a couple of files prior to invoking the C PreProcessor. The first is combined_BareScript.c - which actually serves the purpose of being a header file.
Here's what it has:
//combined_BareScript.c
#include "lrun.h"
#include "vuser_init.c"
#include "Action.c"
#include "vuser_end.c"
The other file created was pre_cci.c which is a concatenation of all our C source files and the lrun.h header file. The lrun.h header contains declarations to various LR API functions we use - particularly the lr_output_message() - and this external symbol can only be resolved if this is present.
The options passed to the pre-processor were defined by MDRV in options.txt. Here's what that file contains:
-+
-DCCI
-D_IDA_XL
-DWINNT
-Ic:\projects\loadrunner\barescript
-Ic:\loadrunner\include
-ec:\projects\loadrunner\barescript\logfile.log
c:\projects\loadrunner\barescript\combined_barescript.c
c:\projects\loadrunner\barescript\pre_cci.c
The GNU preprocessor command line options are documented here.
The -D commands are defines. In effect, MDRV is defining CCI, _IDA_XL and WINNT. The WINNT define is presumably the target platform. The include directories seem to indicate the presence of an LR_UNIX definition. As an exercise, we could try that as an option to see if the output is a Unix-compatible image.
The -I commands are include directory search paths.
The -e command points to a file as an error log.
The last two parameters are the files actually being put through the preprocessor.
The output of this exercise is still the pre_cci.c file.
The next item that got invoked was CCI.exe. Here's what DepWalk found as command-line parameters:
Program Executable: c:\loadrunner\bin\CCI.EXE
Program Arguments: -errout="c:\projects\loadrunner\barescript\logfile.log" -c "c:\projects\loadrunner\barescript\pre_cci.c"
This is straightforward - the -errout is pointing to an error log. The -c is the target to compile - which happens to be our pre_cci.c file.
The output of this process is the BareScript.ci file - our final compiled image.
Dependency Walker 2.0 comes with a rather nifty feature called Application Profiling. This is a technique used to watch a running application to see what modules it loads. Dynamically loaded modules that are not necessarily reported in any on the import tables of other modules can be detected this way.
We start with a barebones script - one having exactly one action with maybe an lr_output_message() and invoke MDRV on it for only the compilation. Initially the script has only the following files: vuser_init.c, Action.c, vuser_end.c, default.cfg, default.usp, BareScript.usr.
The command-line arguments look like this:
mdrv.exe -usr BareScript.usr -compile_only
Application profiling on this automatically causes invocation of cpp.exe. The command-line options passed to CPP.EXE are captured by the App Profiler. Here's what it looks like:
Program Executable: c:\loadrunner\bin\CPP.EXE
Program Arguments: -f"c:\projects\loadrunner\barescript\options.txt"
MDRV has created a couple of files prior to invoking the C PreProcessor. The first is combined_BareScript.c - which actually serves the purpose of being a header file.
Here's what it has:
//combined_BareScript.c
#include "lrun.h"
#include "vuser_init.c"
#include "Action.c"
#include "vuser_end.c"
The other file created was pre_cci.c which is a concatenation of all our C source files and the lrun.h header file. The lrun.h header contains declarations to various LR API functions we use - particularly the lr_output_message() - and this external symbol can only be resolved if this is present.
The options passed to the pre-processor were defined by MDRV in options.txt. Here's what that file contains:
-+
-DCCI
-D_IDA_XL
-DWINNT
-Ic:\projects\loadrunner\barescript
-Ic:\loadrunner\include
-ec:\projects\loadrunner\barescript\logfile.log
c:\projects\loadrunner\barescript\combined_barescript.c
c:\projects\loadrunner\barescript\pre_cci.c
The GNU preprocessor command line options are documented here.
The -D commands are defines. In effect, MDRV is defining CCI, _IDA_XL and WINNT. The WINNT define is presumably the target platform. The include directories seem to indicate the presence of an LR_UNIX definition. As an exercise, we could try that as an option to see if the output is a Unix-compatible image.
The -I commands are include directory search paths.
The -e command points to a file as an error log.
The last two parameters are the files actually being put through the preprocessor.
The output of this exercise is still the pre_cci.c file.
The next item that got invoked was CCI.exe. Here's what DepWalk found as command-line parameters:
Program Executable: c:\loadrunner\bin\CCI.EXE
Program Arguments: -errout="c:\projects\loadrunner\barescript\logfile.log" -c "c:\projects\loadrunner\barescript\pre_cci.c"
This is straightforward - the -errout is pointing to an error log. The -c is the target to compile - which happens to be our pre_cci.c file.
The output of this process is the BareScript.ci file - our final compiled image.
