New VTS(Virtual Table Server) in LoadRunner 11.5 version

          Virtual Table Server (VTS) is a tool that shares data and parameters between LoadRunner vusers. Unlike standard parameterization functionality, VTS use a centralized repository to store data, therefore data can be passed between vusers during the load testing. Below diagram shows how VTS is used in load testing:


 
       In the above diagram, you can first prepare the parameter data by importing tabular data into VTS from other data sources, e.g. database or CSV files. Then follow the below steps to do load test:

1. Start load test from Controller.
2. Controller will in turn launch VUsers on Load Generator machines.
3. In each VUser, VTS APIs can be called to access data from the VTS Server.

     With the release of 11.52, HP has released a whole new VTS, with some enhanced features. The new VTS APIs is backward compatible and can be used in all protocols that uses C language as well as TruClient. You can see the new console UI in the below screen:



Features and Comparision of Old VTS and New VTS:

• Old VTS is a windows based application, which means before running a load test, users have to log on a machine, and manually launch the VTS console in order to start it. And also all the administration work, like importing/exporting data, view the data, can only be performed locally on VTS console machine. New VTS console has web interface and users can manage the VTS remotely using any web browsers like IE, Chrome, and Firefox. It runs as a windows service, and starts automatically when machine starts.

• Old VTS stories everything in memory, which can cause data loss when machine or VTS console crashes. Also, the amount of data stored in the VTS is limited by the memory. The new VTS persists data to disk automatically, using a very fast NoSQL data engine, therefore can achieve high throughput and at the same time avoid data loss.

• For the old VTS, there are some manual work to be done when using it, e.g. add code #include "vts2.h", load the DLL with the statement lr_load_dll("vtclient.dll"), copy the VTS header file, lib file as well as DLL file to each LG machine. These steps are no longer needed for new VTS. As long as every machine is updated to 11.52, you can start using it, no need to add #include statement for any specific header file, or load particular DLL.

• The new VTS is integration into the run logic control of LoadRunner script. For those who are not familiar with the run logic, it is the logic to decide whether to terminate the execution of current iteration or the load test.Old VTS doesn’t have such mechanism, when some API fails because of VTS server issue, user needs to add code to check the last error, log the message, and exit if it fails. With new VTS, a VTS error can cause the current iteration to fail, and error will be logged automatically. Also, user can override this behavior by checking the option “Continue on error” in the Runtime Setting, so that when error occurs to the VTS, it will continue to execute the rest of code.

• Because the console UI of the new VTS can be accessed remotely, we allow user to secure the console UI by enabling basic authentication and https, with some manual configurations.

• Another enhancement is that the new VTS APIs are available to Linux LG, which means that you can also use VTS now if you are running script on Linux LG machines.

• Unicode support. While in LoadRunner C script, multi-byte encoding are still used for all text strings, the VTS server, which is built on top of node.js, fully supports Unicode. That means you can key in the multi-lingual strings on the console UI, or import Unicode text file into the VTS and display them correctly.Whether the string can work correct in the load testing depends on the system locale setting of LG machine. The Unicode string will be converted to multi-byte strings when data is retrieved to the LG during run time, and multi-byte string will be converted to Unicode when save back to the VTS machine. This means you can use a single data source to work with LG machine that in different locales.

• The size of the data supported also increased significantly. We have tested the data of 10 million rows. And the performance of accessing data randomly is a constant, irrelevant to the number of rows stored in the repository.

• Last but not least, compare to old VTS, which is an unsupported tool, now new VTS will be fully supported by HP and if you find any problems using it, or have any suggestions, you can contact support for help.

How to upgrade to the new VTS

         LoadRunner 11.52 also provides users smooth experience upgrading to new VTS. The APIs signatures are fully compatible with the old VTS APIs:

• For anyone who are used to old VTS and want to continue use the old one after applying 11.52, nothing will be change as long as he didn’t change the VTS code. It will continue to work as before. LoadRunner actually decides whether a script is using old VTS or the new one by checking whether it calls lr_load_dll("vtclient.dll") at the beginning and whether "vts2.h" header is included. If these statements exist, LoadRunner will provide you the old VTS APIs. Otherwise, will link these APIs to the new VTS implementation.

• For those who installed 11.52, and want to use the new VTS, they can write similar code as old VTS, just with minor modifications: change type PVCI to PVCI2 and type VTCERR to VTCERR2, and don’t load the DLL "vtclient.dll".

The new VTS consists of two parts, the vuser side is tightly integrated with the LoadRunner, and is installed with 11.52. The VTS server side needs separate download and install.

If you want to use the new VTS, you can take the following steps to install the new VTS and experience it:

• Install 11.52 on all load testing machines, particularly, the VuGen and LG machines.

• Install VTS server on a server machine, it can be a separate machine, or any of existing load testing machine, depends on how much load VTS service will have. You can either install 32 bits version or 64 bits version, depends on your OS type. After installation, the service will start automatically and you can browse to the VTS console UI. The default port is 4000, therefore the URL is something like http://localhost:4000. You can specify a different port during the install or afterwards.

• On the console UI, you can import data by uploading a CSV file, or typing in a connection string to import from database directly. The following screen shows the UI of importing data:

•   Create a C language script, like Web Http/Html script. Add VTS API in vuser_init method to connect to the server, like the following:

int   rc = 0; char  *VtsServer = "192.168.0.100"; int   nPort = 8888;     PVCI2 pvci = 0; vuser_init() {             pvci = lrvtc_connect(VtsServer,nPort,VTOPT_KEEP_ALIVE);     lr_log_message("pvci=%d\n", pvci);             return 0; }

• In Action.c, add some code to retrieve one column from the server and remove from the server at the same time. You can run the action multiple iterations, and it will retrieve one:
  
  

char * cname; //column name int ret; RetrieveMessage() {     lr_start_transaction("retrieve_column");     rc =  lrvtc_retrieve_messages1("cname",";");     lr_log_message("lrvtc_retrieve_messages1 rc=%d\n", rc);     lr_log_message("cname is %s", lr_eval_string("{cname}"));     lr_end_transaction("retrieve_column", LR_AUTO); } Action() {     RetrieveMessage();     return 0; }

• In vuser_end.c, add API call to close the VTS handle:

vuser_end() {     lrvtc_disconnect();        return 0; }

• You can test it in VuGen and run it in Controller. Don’t forget to turn on the API access port before you run the script. Like old VTS, the new one use 8888 as the port for API to access. It is turned off by default, so you need to browse to the administrative UI to enable it.