Url Redirector Modified



 

Load Testing of a FatClient, Middleware or Non-UI Application

Most of the people refer load as concurrent users. It is not 100% true. Load is the combination of users and how fast the users are working on the server. Let us take an example of an email web application. We need to load test this web application with 100 concurrent users reading the emails. 100 users can read the email in a different ways. One way is, each user will read the email once in an hour. So there will be 100 emails read/ hour. Another way is, each user will read 10 emails in an hour. It will result in 1000 emails / hour. In the second case, users are working faster and leading to more load on the server. So in other words, number of users and number transactions per hour determines the load on the server. So testing the server with realistic load to simulate a business peak hour.  In real time, if the application has 100 concurrent users reading 1000 emails / hour, load testing is the simulation of the same scenario.


The load testing of fat client applications are comparatively complex compared to the web applications. It is due to the type of network communication happening between the client and the server. Another reason is lack of support for the fat clients in load test tools. It adds more challenges to the complexity when the client software runs on a Hand Held device.  However, these challenges can be overcome by utilizing the flexibility of the load test tools and using them in a right way.

SQL Anywhere Load Testing Approach

Sybase SQL Anywhere is a database and synchronization technology operates in an application which works outside traditional data centers. One of those types of application is Hand Held (HH) device. The load test of SQL Anywhere HH application by simulating hand held device is a tricky task.  


This section presents an approach for load testing SQL Anywhere using LoadRunner. Following are discussed here.

  • Architecture of SQL Anywhere hand held and SQL Anywhere server


  • Performance Testing challenges of SQL Anywhere server


  • A solution in LoadRunner even though LoadRunner does not support SQL Anywhere Hand Held testing out of the box.


  • Detailed approach to implement the LoadRunner solution.

.





SQL Anywhere Load Testing Challenge

SQL Anywhere consists of client software which runs in the Hand Held (HH) device and server software which runs in the centralized server. Hand Held device stores the data locally and uploads the data to server whenever a network connection is available. Upload process uses proprietary messaging protocol built on TCP/IP. In production scenario, multiple HH devices can be connected to the server and uploads the data. The below diagram shows the high level architecture of the application.


SQL Anywhere client has 4 components such as QA client, QAnywhere API, SQL Anywhere Database and QAAgent. QA client provides the interface to the end user and helps the user to do activities on the HH device. Client utilizes QAnywhere APIs (.Net, Java, C++) to communicate with local SQL Anywhere database. Internally, this local database implements a queuing system. The database can queue the message until the HH is connected to the server.  QAAgent manages the communication between HH device and the server. Agent does this communication by pulling the data from local database queue and sending to the server. On the other side, server has QAnywhere server and the SQL Anywhere database. The data received by QAnywhere server from QAAgent will be saved in central database server.

  1. QA client uses QAnywhere APIs
  2. QAnywhere APIs talk to local database queue and store the messages.
  3. When QAAgent establishes the connection with the server, it retrieves the messages from the queue.
  4. QAAgent uploads the data to the QAnywhere server
  5. QAnywhere server stores the messages in the server database.


The traditional load testing approach in LoadRunner is to record the client/server communication listening to the client, customize the recorded data and use it to simulate multiple clients. Following are the challenges to implement a traditional approach.

  • LoadRunner can not be hooked up the client to record the client/server traffic since it is deployed in a Hand Held device.
  • Client/server Network traffic will be in binary format and can not be interpreted easily to customize and simulate multiple clients.
  • LoadRunner does not support SQL Anywhere load testing out of the box.
  • Any other tool in the market can be expected to have same challenges in LoadRunner.
Load Testing Solution
In traditional load testing approach mentioned above, LoadRunner do the simulation by not simulating the client software but simulating the traffic from client to the server. Since traditional approach is far from reality, only way is to come up with a solution making use of client software and Load Runner flexibility. The approach is to engineer a solution which will s
tart SQL Anywhere client software in the load generator computer which will act as the simulated Hand Held. And inject messages to simulated Hand Held which will in turn upload the messages to the server.

Following are the advantages of this solution
  • Hand Held simulator is not required to record the traffic from Hand Held device in a desktop computer.
  • Not required to customize a complex binary data script.
  • A robust solution which can simulate large number of HH device per each load generator machine.
  • Solution which is scalable to simulate more concurrent devices making use of LoadRunner scalability potential
  • Highly scalable and re-usable approach to test large growth in the future.

Solution Details

A LoadRunner script can developed in C language making use of system command in LoadRunner. It will start multiple instances SQL Anywhere database and QAAgent software in the load generator machine. Following logic can be written in the script.

//Code to create unique name for database client and build SetupClient.cmd

//SetupClient.cmd file will run in the load generator which will start the client database executable with unique database name

system (“SetupClient.cmd”); //system command which will invoke SetupClient.cmd


//Code to create unique name for QAAgent and build StartAgent.cmd

//StartAgent.cmd will start the QAAgent executable with unique agent name

system (“StartAgent.cmd”); //system command which will invoke StartAgent.cmd


Above mentioned script can be assigned to multiple load generators and each load generator can simulate multiple vusers. Each vuser will act as simulated Hand Held device. Following diagram shows how the script will generate multiple simulated Hand Helds in 3 different load generators. 


Once the simulated Hand Helds are up and running, the next step is to start injecting the messages to the local database in the device. It can be achieved by another script. This particular script can be written in Java template vuser using SQL Anywhere Java APIs. These APIs will communicate with database and drop the message to the queue. Following logic needs to be developed in the injection script.



//In init section of loadrunner script

//Get instance QAManager object using createQAManager() function

//Set connection parameters to the created QAManager instance using setProperty() function. Unique database names created in the first script needs to be used here.

//Open the connection using open() function


//In action section of LoadRunner script

//Build the message to send. Depends on the end system message can be free text or valid //business objects like Customer Order, Sales receipt etc...

//Drop the message using putMessage() function.


Message Injection script needs to assigned to the exact same load generator where the simulate Hand Helds are running.  When the injection script is started, it will start pumping the messages to the respective local databases. Since QAAgent is already started by previous script, as soon as the message arrives in the local dataset queue, agent will start retrieving the messages and send to the server. Following diagram shows the message injection implementation.


Conclusion

Even though load testing of SQL Anywhere application pose challenges to us, it can be seen that using the right approach and tool can resolve this issue.  Also, it can be concluded that generating load on the server by record and replay will not work in all the cases and we need to look for novel ideas of engineering solutions. This above mentioned strategy is an example of one of such solutions.

Performance Testing Fun