HPE has released the latest version of StormRunner Load – v2.0. A lot of new features were introduced or enhanced in StormRunner. Let us see what HPE has got in-store for the performance testers with this new release.

Main Features:

HPE has released their new SAAS performance testing solution called StormRunner Load. HPE StormRunner Load is a SaaS based cloud load and performance testing solution that makes it easy to plan, run, and scale agile web and mobile testing. Let us see what HPE has got in-store for the performance testers with this new release.

StormRunner provides you with the tools to create load tests and generate the metrics to analyze your application’s system performance.

COM/DCOM is one of the toughest load runner protocols to deal with. It is always good to go through these error handling tips and tricks whilst using COM/DCOM protocol.  These are some of the errors you might encounter whislt using COM\DCOM protocol in HPE Load Runenr.
Protocol: COM/DCOM
Tool: HPE Load Runner

  1. Error: Vuser failed to initialize extension vbascriptext.dll.
    Reasons: VBA not installed on the Controller or Vugen Machine
    Solution: Install the VBA Setup from the start->All Programs-> Load Runner -> Tools -> VBA Setup
  2. Error: 3021 – Either BOF or EOF is True, or the current record has been deleted.
    Requested operation requires a current record
    Reasons: While recording, LoadRunner saves the content of a recordset into a file using the save function from ADO::Recordset.
    To implement this, LoadRunner will move the pointer to the EOF. If the application cannot detect the pointer position,
    and tries to move the pointer that is already at the EOF, it will cause a problem or crash.
    Solution: Turn off the “Save recordset content” options in Recording Options
    Turn off the “Save recordset content” option in Recording Options. This will allow the application to move on, but it will
    also lose the Grids.
  3. Error: VBA Script Error: Either BOF or EOF is True, or the current record has been deleted. Requested operation requires a current record.
    Source: ADODB.Field
    wCode: 0 (0x00000000)
    sCode: -2146825267 (0x800a0bcd)
    Help Context: C:\WINDOWS\HELP\ADO270.CHM (1240645)
    Reasons: If the record you are looking for does not exist in the current context.
    Solution: Stage data properly
  4. Error: 0x800a0006 Buffer Overflow
    Reasons: Type Conversion problem. Trying to convert a value larger than 32767 into an integer. (error occured when OrderNumber is greater than 32767)
    Solution: try using clng instead of cint.
  5. Error: 0x800A000D Type mismatch
    Reasons: wrong Type for the sending argument
    Solution: clng,cbool,cint,cstr etc
  6. Error: 0x800A005B Object variable or with block variable not set
    Reasons: permissions
    Solution: give the user complete folder permissions
  7. Error: Run-time error 383. ‘Text’ property is readonly
    Reasons:
    Private Sub Form_Load()
    With Combo1 ‘Style = 2 Dropdown list
    .AddItem “One”
    .AddItem “Two”
    .AddItem “Three”
    End With
    End SubPrivate Sub Command1_Click()
    ‘No error
    Text = “Two”
    End SubPrivate Sub Command2_Click()
    ‘383 error
    Combo1.Text = “Four”
    End Sub
    Solution: Pass the correct value for the drop down boxes
  8. Error : ADODB.Recordset (0x800A0E78)Reason:
    set dbs = Server.CreateObject(“ADODB.Connection”)dbs.Open strODBC
    set rst = dbs.Execute(strSQL)

    Do not use a recordset to execute a query that does not return records. in
    fact, tell ADO not to bother constructing an expensive recordset object:
    dbs.Execute strSQL,,129

    The 129 is a combination of 1 (adCmdText) and 128 (adExecuteNoRecords). If
    you have a metadata tag referencing the ADO type library dbs.Execute strSQL,, adCmdText + adExecuteNoRecords

    Solution: use simple queries to update or insert.

  9. If you get PID not found Error while recording then follow the below steps:
    • Record the script without any libraries added.
    • Find  for the error in the script
    • lrc_Properties_get_Count (error! not found PID: 3852 interface pointer address: 03D68660, &c, CHECK_HRES);
    • select this PID number-3852 and search for it in the interface.h file in the script below action
    • copy the GUUID code like this {6FE588D3-D223-4C20-B16B-BC6564710856}
    • go to recording options-type libraries-exclude-enter this value in GUID field -ok
    • Then record the script again.
  10. Adding Libraries.How to find the libraries which we need to add before recording.

    Need to ask the Project team about which libraries will really create load on the server.

    Record the script without any libraries added.

    Go to script folder->Data->lr_debug_list-xxx-> and add all the libraries written in this file to the Recording options –Type library –Add

    Record the script again with these recording options again.

    Adding the libraries is more important, because if you are not adding the libraries the script will be small, but while replaying the exe (i.e. application) is not getting listed in the task manager. It means the script is just running without invoking the application.

  11. Getting Spill Too large Error while Replaying.After the scripts are recorded, while replaying with extended log, In the middle of replaying you will get Spill too large error and the vugen will close or hang.
    • Close the script and clear the temp.
    • Go to tools-option- disable runtime viewe
    • Run the script

     

It is always wise to follow a set of rules whilst conducting performance testing for any technology/app. These rules ensures that your test run is error free and less time consuming. Please find below some of the best practices to be followed:

  • Do Not Place Too Much Stress on the Client
    Do not overly stress the client computer used to generate application load. The processor and memory usage on your client computers should be well below the threshold limit (CPU: 80 percent). Otherwise, the client computer may end up as a bottleneck during your testing. To avoid this, consider distributing the load on multiple client computers. Also, monitor the network interface bandwidth utilization to ensure that the network is not getting congested.
  • Create Baselines for Your Test Setup
    Create baselines for your test setup for all types of tests you need to perform. The setup should be representative of the real life environment. This has two advantages. First, the results from various categories of tests do not reflect the type of hardware you are using. This means that your application modifications are the only variable. Second, you can depend on the test results because the test setup closely mirrors the real life environment.
  • Allow for Think Time in Your Test Script
    Think time reflects the amount of time that a typical user is likely to pause for thought while interacting with your application. During this time, the user views the information displayed on the page or enters details such as credit card numbers or addresses. You should average the think time across various operations.
    If you do not include think time in your script, there is no time gap between two subsequent requests on a per-user basis. This directly translates to all users firing requests to the server concurrently. So, for a concurrent load of 200 users, there will be 200 requests fired at a given instance to the server. This is not a true representation of how your typical users use your application.
    Note: Omitting think time can be helpful when you want to generate excessive load on the server.
    Make sure that the think time in your test script is based on real life conditions. This varies according to the operations performed by the user, and it varies depending on the page the user is interacting with.
    For your test scripts, you can program for either a fixed think time between consecutive requests or a random think time ranging between minimum and maximum values.
  • Consider Test Duration
    You should base the time duration for your tests on the end goal. If the goal is to load test and monitor the application behavior for your workload pattern, the test duration might range from 20 minutes to as long as one week. If the site is expected to experience users of similar profile, and the average user is expected to perform the same set of operations during the intraday activity, a test of 20 minutes to one hour is sufficient for generating data for load testing. You may want to run load tests for an extended period — four to five days — to see how your application performs on the peak operating capacity for a longer duration of time.
    However, to generate test data for your site if your site expects users of different profiles during various hours of operation, you may need to test for at least eight to 10 hours to simulate various user profiles in the workload pattern.
    For stress testing purposes, the end goal is to run tests to identify potential resource leaks and the corresponding degradation in application performance. This may require a longer duration, ranging from a couple of hours to a week, depending on the nature of the bottleneck.
    For tests used to measure the transaction cost of an operation using transaction cost analysis, you might need to run test for only approximately 20 minutes.
  • Minimize Redundant Requests during Testing
    Make sure that your test load script simulates an appropriate load for your particular scenario and does not generate additional redundant requests. For example, consider a logon scenario. The complete operation typically consists of two requests:
    * A GET request used to retrieve the initial page where the user supplies a logon name and password.
    * A POST request when the user clicks the Logon button to verify the credentials.The GET request is the same for all users and can easily be cached and served to all users. However, it is the POST request that is critical from a performance perspective. In this example, your test script should avoid sending a GET request before submitting a POST request. By avoiding the GET request within your test script, the client threads of the load generator are able to iterate faster through the loop for a given set of users, thereby generating more POST requests. This results in a more effective stress test for the actual POST operation. However, there may be conditions when even the response to a GET request is customized for a user; therefore, you should consider including both the GET and POST requests in the stress tests.
  • Consider Simultaneous vs. Concurrent Users
    Simultaneous users have active connections to the same Web site, whereas concurrent users connect to the site at exactly the same moment. Concurrent access is likely to occur at infrequent intervals. Your site may have 100 to 150 concurrent users but 1,000 to 1,500 simultaneous users.
    To stress test your application by using tools such as ACT, use a think time of zero in your test scripts. This allows you to stress your application without any time lag, with all users concurrently accessing the site. By using an appropriate think time, however, you can more accurately mirror a real life situation in which a user takes some time before submitting a new request to the server.
    High numbers of simultaneous users tend to produce spikes in your resource usage and can often cause interaction that is beyond the concurrent load a server can handle. This results in occasional “server busy” errors. Tests with simultaneous users are very useful because they help you identify the actual load your system can handle without sending back too many server busy errors.
  • Set an Appropriate Warm-up Time
    ACT supports warm-up times. The warm-up time is used in a test script to ensure your application reaches a steady state before the test tool starts to record results. The warm-up time causes ACT to ignore the data from the first few seconds of a test run. This is particularly important for ASP.NET applications because the first few requests trigger just-in-time (JIT) compilation and caching.
    The warm up time is particularly relevant for short duration tests, so that the initial startup time does not skew the test results.
    To determine an appropriate warm-up time for your application, use the ASP.NET Applications\Compilations Total counter to measure the effects of JIT compilation. This counter should increase every time a user action triggers the JIT complier.
    In some cases you may want to know how long it takes to compile and cache. It should be a separate test; it should not be averaged into your steady state measurements.

Dos & Don’ts:

Dos:

  • When performing performance testing, make sure you do the following:
  • Clear the application and database logs after each performance test run. Excessively large log files may artificially skew the performance results.
  • Identify the correct server software and hardware to mirror your production environment.
  • Use a single graphical user interface (GUI) client to capture end-user response time while a load is generated on the system. You may need to generate load by using different client computers, but to make sense of client-side data, such as response time or requests per second, you should consolidate data at a single client and generate results based on the average values.
  • Include a buffer time between the incremental increases of users during a load test.
  • Use different data parameters for each simulated user to create a more realistic load simulation.
  • Monitor all computers involved in the test, including the client that generates the load. This is important because you should not overly stress the client.
  • Prioritize your scenarios according to critical functionality and high-volume transactions.
  • Use a zero think time if you need to fire concurrent requests,. This can help you identify bottleneck issues.
  • Stress test critical components of the system to assess their independent thresholds.

Don’ts:

  • Do not allow the test system resources to cross resource threshold limits by a significant margin during load testing, because this distorts the data in your results.
  • Do not run tests in live production environments that have other network traffic. Use an isolated test environment that is representative of the actual production environment.
  • Do not try to break the system during a load test. The intent of the load test is not to break the system. The intent is to observe performance under expected usage conditions. You can stress test to determine the most likely modes of failure so they can be addressed or mitigated.
  • Do not place too much stress on the client test computers.

Hurray!!! HPE has released the latest version of Load Runner v12.53. It brings a lot of new features along with improvisations on the existing ones. Let us see what HPE has got in-store for the performance testers with this new release.

Main Features:

  • Git integration in VuGen
  • 64-bit replay support in various Java protocols and C Vuser protocol
  • New PCoIPLatest up (remote access) protocol
  • Enhanced SAPUI5 recording in TruClient
  • HTTP Video Streaming (HTML5, HLS) support
  • HTTP/2 support
  • REST step-builder editor in VuGen
  • JSON manipulation APIs
  • Web – HTTP/HTML and Mobile Application – HTTP/HTML protocol unification
  • Linux load generator improvements
  • Enhancements to Java-based protocols