Performance Testing Flex Applications using LoadRunner(转载）

Performance Testing Flex Applications using LoadRunner

 

 

Abstract

This article provides recommendations for engineers in testing the flex applications using LoadRunner, as well as the typical issues & solutions that challenge the performance tester to test the flex application using LoadRunner. In a typical flex application, user can perform quite a few tasks with the SWF file on the browser. During these activities, the user actions do not make any calls to the backend. So, QTP users are included to capture the real user experience response time. Integrating QTP with Flex & LoadRunner also has many challenges. This article does not provide detailed information on identifying bottle neck & performance tuning suggestions specific to flex. However, links to the standard approaches & references articles posted by Adobe, HP are listed in this article.

Introduction

This article contains a high-level overview of the architecture of Web application with Flex and a brief review of testing tools and with recommendations on use for effective performance testing of the flex applications. These recommendations are based on the real time experience, adjusted to the requirements of flex application under test.

Understanding Flex & LoadRunner

Before testing the application with any tool, one should be aware of flex as a technology and how it integrates with the web applications. Flex applications have a very appealing & easy user interface. The architecture of web applications with flex is not typical, and you will need to understand the most commonly used terms like, Blaze DS, LCDS, MXML, AMF, SWF, RTMP and DTO. In the next sections, you will see information on different types of flex communications, advantages of AMF over conventional HTTP& SOAP communication methods.

Architecture of Web Applications with Adobe Flex

A compiled Flex application runs on the client’s computer in Web browser’s Flash Player plug-in. When the byte code (SWF file) arrives to Flash Player, the latter applies so called Just-in-Time compiler to turn it into a platform-specific binary code.

Each application has an HTML page with embedded SWF file that communicates with the server side application that can be a Web service, JSP, ASP, PHP, Plain Old Java object(POJO), and any other programming language that can process HTTP. Besides HTTP protocol, Flex application can connect to the server-side application via more effective binary AMF and RTMP protocols described later in this document. On the client side, a Flex application (the SWF file) can communicate with the JavaScript code located in the HTML wrapper.

Flex can connect to the servers that run SOAP Web Services, and Flex Builder provides a data wizard that simplifies working with SOAP. Even though Flex applications can be written in a way that don’t require any changes in the existing HTTP-based server-side applications, it is beneficial to introduce one of the existing implementation of AMF or RTMP binary protocols that greatly improves performance of the data-intensive applications. These AMF & RTMP protocols play an important role here from a testing tool perspective, as the LoadRunner interprets the communication in a binary format, and it is not readable by the user and modify.

Architecture of Web Applications with Adobe Flex

Communication Protocols

LCDS is an excellent solution for building scalable RIA, but it’s not cheap. Adobe has released BlazeDS, an open source implementation of AMF communication protocol. BlazeDS was offered as a free but scaled down version of LCDS (no RTMP and Data Management Services) that supports of a modest number of concurrent users when Flex remoting via AMF is in use. Even though messaging is supported in both BlazeDS and LCDS, the former uses AMF streaming, with a near real-time server side data push, while the latter is designed using the real-time message push from the server.

Following are the differences between LCDS and BlazeDS in terms of features. For more details on the features, please visit http://www.adobe.com/products/livecycle/dataservices/features.html

X – Indicates the feature is available

Features	BlazeDS	LCDS
Data management Services
Client-Server synchronization	X
Conflict resolution	X
Data paging	X
SQL adapter	X
Hibernate adapter	X
Document Services
LiveCycle remoting	X
RIA-to-PDF conversion	X
Enterprise-Class Flex application services
Data access/remoting	X	X
Proxy service	X	X
Automated testing support	X
Software clustering	X	X
Web tier compiler	X	X
Enterprise Integration
WSRP generation	X
Ajax data services	X	X
Flex-Ajax bridge	X	X
Runtime configuration	X	X
Open adapter architecture	X	X
JMS adapter	X	X
Server-side component framework integration	X	X
ColdFusion integration	X
Offline Application Support
Offline data cache	X
Local message queuing	X
Real – Time Data	X
Publish and Subscribe messaging	X
Real -time data quality of service	X
RTMP tunnelling	X

The following table provides definitions for the most common terms:

Action Script	A script programming language used for controlling Flash movies and applications. Its syntax is similar to JavaScript.
AMF	A proprietary binary communication protocol used for Flash Remoting.
Flash Remoting	Flash Remoting allows data to be exchanged between a Flash Player and an application server using the AMF format.
Flex	An application server for generating RIAs (Rich Internet Applications).

Action Message Format (AMF) is a binary format used to serialize Action Script objects. Once serialized an AMF encoded object graph may be used to persist and retrieve the public state of an application across sessions or allow two endpoints to communicate through the exchange of strongly typed data.

Refer to this link for AMF details from Adobe AMF3 specifications from adobe.

HTTP is supported by all Internet browsers and servers. Therefore, HTTP is a preferred method of communication between client applications and servers when working over the Internet. SOAP, an XML-based format, provides a secure way to communicate between applications over HTTP. However, since the messages are text- based, SOAP is inefficient when working with large messages such as Flash files and other RIAs (Rich Internet Applications). To overcome this inefficiency, Macromedia created this proprietary protocol, AMF (Action Messaging Format), which communicates over HTTP in binary format. The binary AMF data set is considerably smaller than that of SOAP’s text-based XML.

A typical client application that submits AMF messages to a server is the Flash Player, which sends native Flash objects to an application server via a gateway. The gateway, known as the Flash Remoting gateway, is a server-side object, installed on either a Java or .NET server. The gateway acts as a broker that handles requests between the Flash Player and the server. It translates Flash objects into native objects for the server and passes them on to the appropriate server-side services. After the results are returned, the gateway serializes them back into native Flash objects and sends them to the Flash client via AMF.

RTMP protocol is not HTTP based. It supports direct socket-to-socket communication and requires an open port. This may represent an issue with the clients that connect via a firewall.

Refer to this link for Real-Time Messaging Protocol (RTMP) specifications

As mentioned before, RTMP is not supported by Blaze, and many of the applications that you often come across at an enterprise level are built on Blaze sever. RTMP doesn’t come into picture, unless you see application is enabled with delivery of video, audio, and data in the open AMF, SWF, FLV, and F4V formats compatible with Adobe Flash Player.

Sample Application under Test

The test application runs on any browser provided the browser has Flash Player 9 or above installed. All communications between the Client and Server happen through Blaze DS and AMF channels residing on the Java server (Blaze DS & AMF Channel forms the Interaction Services Layer on the Java Server replacing the need to use Controller Servlets).

Blaze DS allows the Flex Client to communicate with the Java Server with very less coding effort. The communication is highly reliable and robust. Action Script classes is converted to simple POJOs understandable by the Java Server. Application client is a composition of MXML, Actions Scripts and Data Transfer Objects which can then be run at the user’s browser through Flash Runtime after compilation. One of the prerequisites for the user will be to install Flash player 9 which will provide Flash Runtime in the browser. The Flash Runtime (like JVM) will convert the compiled code and render it to the user’s browser.

All GUI designs are saved as MXML files and its corresponding actions in the action script file. Each front end field (MXML component) is tied to a property in the DTO which will allow any data changes to be reflected in the screen during a refresh (Flash allows an auto refresh of the browser at a certain rate). The process of tying a front end field to the Data Transfer Object is called Data binding. DTOs are manipulated by actions described in the action script through calls to the server.

Following are the Hardware & software specifications of the test application:

ACE Content Switch, IHS 6.1 Web Servers, WAS 6.1 Application Server Cluster, Siteminder, WebSphere Message Broker, External Web services, and a UDB Database.

Testing tools

LoadRunner 9.52 & Quick Test Professional 10.0 is the two tools used in the performance testing of application. Though QTP is considered as a functional automation tool, QTP users are used to emulate the users to capture the end user response time inclusive of the paint time on the browser. Information related to the tools, versions, compatibilities, and makeovers that occurred during the test process are explained in detail in the following sub sections.

LoadRunner Versions: As per recommendation from HP, LoadRunner 9.52 has improved support for flex. After installing the LoadRunner 9.5, the two patches 9.51 (PC_00238) & 9.52 (PC_00244) have to be installed to upgrade the version to LoadRunner 9.52.

Compatibility: There are no compatibility dependencies for these two patches. Once the 9.5 version installed as per the documentation, the patches can be applied directly. If you happen to see any version mismatch errors, contact the HP support team to get the right patch (patches vary for LoadRunner & Performance Center).

Plugins: No additional plugins are required for the LoadRunner to record the flex applications after the 9.52 upgrade.

Scripting Recommendations

Provided below are detailed instructions on scripting the flex application, tips & techniques that will certainly provide ease with your scripting exercise.

Difference in Recorded Scripts with & without Serialization

When you record a flex application using LoadRunner for the first time using flex protocol or a web protocol, you will observe that the LoadRunner captures the communication in a binary format; this is because of the AMF protocol under use. AS explained in the earlier sections, AMF is a binary format used to serialize Action Script objects. The flash gateway translates Flash objects into native objects for the server and passes them on to the appropriate server-side services. After the results are returned, the gateway serializes them back into native Flash objects and sends them to the Flash client via AMF.

With the LoadRunner recorded content being binary, it is very difficult to parameterize & correlate the different requisite parameters, for the script to handle multiple users and requests when run through a controller or VuGen. To get around this problem, you have to use the Java classes from the Flex server to serialize AMF messages in your script. After serialization, the script will be in a readable xml format. Below provided are two snapshots of scripts with and without serialization (These snapshots just represent the AMF communications, and not any RTMP communication)

Without Serialization

With Serialization

Recording Settings in VuGen

The protocol to be selected is ‘flex’ from the ‘E-Business’ category of the VuGen protocol list. Always select the three listed protocols from the ‘Protocols’ section of Recording options to capture all the HTTP and AMF protocol communications that take place with the user actions. In this case, it is not required to select ‘New Multiple Protocols Script’ from the initial selection list of new script in VuGen. Two protocols (AMF and HTTP) are listed along with flex Protocol in the Recording options because flex supports Data formats such as Http, AMF and SOAP.

While recording the flex applications, it is quite possible that you would come across a situation, where the browser tends to close automatically. In that case, it is advised to try the following actions.

As a first measure, Choose Recording options –> Network –> Port Mapping –> set Capture Level to ‘WinINet level data’

If you still happen to see issues with the browser crashing in middle of the recording, adopt the second option with the registry key change.

Changing the registry key HKEY_CURRENT_USERSoftwareMercury InteractiveLoadRunnerProtocolsHTTPAnalyzer in the registry and set AddNoCacheHeaderToHtml to 0.

However, if you are testing a flex application that has some live streaming videos or data streaming involved (most likely a LCDS application) will have some RTMP communication in place as part of the user action. In that case, it is mandatory to capture the socket level communication that RTMP does with the server. RTMP doesn’t support HTTP, only supports direct socket-to-socket communication and requires an open port.

Choose Recording options –> Network –> Port Mapping –> set Capture Level to ‘Socket level and WinINet level data’.

If you are using BlazeDS or LCDS, It is always preferable use the ‘Custom java classes’ option. It is advisable to obtain the latest flex jar files from the application development team. (Below image for BlazeDS application type)

Depending on the server type, add the following JAR files:

BlazeDS: flex-messaging-common.jar, flex-messaging-core.jar

LCDS: flex-messaging.jar, flex-messaging-common.jar

Common jar Files:

flex-messaging-common.jar

flex-messaging-core.jar

flex-messaging-data

flex-messaging-data-req

flex-messaging-opt

flex-messaging-proxy

flex-messaging-remoting

wilog4j

It is not mandatory to enable the ‘Externalizable Objects’ during the recording. The recorded requests can even be serialized, using the ‘Regenerate Script’ option from Tools section of VuGen. To avoid serializing the request during recording, select ‘Do not serialize externalizable objects’ option from recording options.

Code Generation Errors

At times, VuGen generates a flex_web_request step containing binary data which are not serialized. When this occurs, the Code Generation Errors opens automatically after code generation with a message indicating that there was a problem with externalizable objects. You could expect for this kind of errors for the first time. These errors are due to missing classes or folder paths that prevent the tool from serializing the binary content.

The error window will provide detailed description on the error, and the missing class files/folders. Usually, these class files/folders refer to the application specific jar file/folder. Identify all the mandatory files from each error displayed and add them along with the other files in the ‘Externalizable Objects’ section of recording options. The easiest way is to get the latest and complete jar file from the development team and upload them as a single zip file. Make sure to place all the corresponding jar files in the same path. Click on the ‘Generation Options’ button to open the recording options dialog box, and upload the latest jar file in the ‘Externalizable Objects’ section. Regenerate the script and repeat the procedure until there are no more missing Java classes.

Script Development

When all the flex_web_request calls are converted to flex_amf_call, the script development is quite easy.

Flex applications consist of many MXML and Action Script files. They are compiled into a single SWF movie file which can be played by Flash player, installed on the client’s browser. It supports a variety of client/server communication methods, such as RPC, Data Management, and Real-Time messaging (RTMP). It supports several data formats such as HTTP, AMF, and SOAP.

In all the flex applications, the most common parameter that needs to be correlated is the session Id that is shown in as ‘DSId’, and the rest of them are application and test case specific. In the next sections, the script correlation is described in detail.

If you closely observe the script, throughout the requests there are always unique alphanumeric value of string length 32. These are also type session ids (Other than DSId) tagged to each request (may be 1 or 2 or more). These values change every time you record a new baseline and these are not generated from the server’s response. These values are generated from particular java method employed in every request on the browser, and these values can be left hard coded or parameterized or can be replaced by calling the same java method that was implemented in the application. It doesn’t really impact the script, even if these values are not set to change dynamically.

The most common flex requests that you notice in the script are:

flex_web_request Allows you to create a custom HTTP request with any method supported by HTTP.

flex_rtmp_connect Connects a client to an RTMP server and sets connection options.

flex_rtmp_disconnect Disconnects a client from an RTMP server.

flex_rtmp_send Sends messages to an RTMP server.

flex_rtmp_receive Receives responses from an RTMP server.

flex_amf_call Sends a Flex AMF request.

For rest of the functions and details on each function & their operation, please refer to the HP LoadRunner Online Function Reference > Flex Functions (FLEX)

Correlation & Parameterization of Flex Scripts

Correlation in flex scripts is quite easy and similar to the way it is done in web or webservices. A flex_amf_call doesn’t recognize the web functions used in the web application scripting. Only LR XML functions can be used to the get, set, extract, find and so on from the flex_amf_call response. Unlike the web_reg_save_param, these XML functions are placed after the corresponding amf calls that generate the required response.

The most common functions used in developing the script are:

lr_xml_get_values: Retrieves values of XML elements found by a query

lr_xml_set_values: Sets the values of XML elements found by a query

lr_xml_extract: Extracts XML string fragments from an XML string

lr_xml_replace: Replaces fragments of an XML string

lr_xml_find: Verifies that XML values are returned by a query

For rest of the functions and details on each function & their operation, please refer to the HP LoadRunner Online Function Reference > XML Functions (LR_XML)

Correlation instructions as per the VuGen Reference Guide

Instructions provided here are shortened version of instructions:

• Save the server response in preparation for extracting the required values.
• Extract the required values from the server response.
• Save the values to a parameter.
• Use those parameters as input to your Flex requests.

To perform correlation:

• Locate the step in your script that failed due to dynamic values that need correlation.
  • Use the Replay Log to assist you in finding the problematic step.
• Identify the server response with the correct value in one of the previous steps.
  • Double-Click the error in the Replay log to go to the step with the error. Examine the preceding steps in Tree View and look for value in the Server Response tab.
• Save the entire server response to a parameter.
  • Before you extract the value, the entire server response should be saved to a parameter as follows:
    • Right-click the step node (in the left Action pane) corresponding to the server response containing the value and select Properties.
    • In the Flex Call Properties dialog box, type a Response parameter name.
    • Click OK to save the new parameter name.

• Save the original server response value to a parameter.
  • In the Replay Snapshot: Response Data, right-click the node above the value (for example, string), and select Save value in parameter.

• In the XML Parameter Properties dialog, specify a parameter Name. You will use this name in subsequent steps.
• Click OK. The script will now contain a new function, lr_xml_get_values.

Insert the parameter in the subsequent calls. In VuGen edit view, beginning with the call that failed, replaces the value in all subsequent calls to the object with the parameter that you defined. Right-click the step node (in the Action pane) corresponding to the failed call and select Properties. Locate the argument that required correlation. In the Value box, type the parameter name in curly brackets, for example, {ParamValue_string}. Click OK.

• Run the script
  • Make sure that VuGen properly substitutes the argument value with the parameter value that you saved.

Refer to VuGen reference guide for more details HP LoadRunner Virtual User Generator User’s Guide > Protocols > Flex Protocol > About Developing Flex Vuser Scripts

Run-Time Recommendations

Once the script development is over, there are key things to be validated before running them in VuGen or Controller for multiple iterations & users respectively.

In the script, if the user Login is within the ‘Action’, make sure to select the option ‘Simulate a new user on each iteration’ option. It is also possible for the script to fail in the second iteration, if the option ‘Check for newer versions of stored pages every visit to the page’ is not selected. This error occurs when the application is performing NTLM authentication using Siteminder.

If your applications doesn’t support RTMP, selecting the below option or not doesn’t make any difference. However, on a standard note it is always preferable to select this option as this automatically closes all open sockets at the end of iteration.

The next important runtime setting is the Externalizable objects. The script was generated using the custom java classes to serialise AMF messages. During replay, the same set of java classes located in the same path must be included in the runtime. As LoadRunner serializes the amf binary data to XML data using these flex & application specific jar files, in order to post the request to the server LoadRunner still requires the same jar files & folders.

After replaying the script, always compare the recorded output window with response window in the tree view mode to validate the response. If you understand the application and the service call operation, it would be easy to identify the generic errors that the application might throw, and can be set as rules with Content Checks.

During the test executions in controller, sometimes the scripts throw an error ‘Decoding of AMF message failed. Error is: Externalizable parsing failed’. This is mostly due to the file transfer problem. It is always advised to place the jar files in a share path common to all load agents.

Other Flex Supported Load Testing Tools

There are other Commercial & Open source tools available, that support the flex application testing. Some tools (For example, Neoload) have much considerable support for RTMP even when compared to LoadRunner. The way all these tools test the flex application is quite similar, each tool has its own AMF/XML conversion engine, which serializes the binary data to readable XML format. Please refer to the user guides for different tools from the links provided below.

Open Source

Data Services Stress Testing Framework

The Data Services Stress Testing Framework helps developers using LiveCycle Data Services ES 2.6 load test the server-side implementation of their LCDS applications. This is a tool for putting load on the server and is not meant for stress testing an individual Flex/BlazeDS/LCDS application running in the Flash Player. This framework is not currently compatible with Blaze Data Services although BlazeDS support is planned for future versions of the tool.

Data Services Stress Testing Framework

JMeter

Below provided link has information that helps to generate custom AMF requests in JMeter. There are many articles available online on how to generate custom AMF requests using JMeter, provided here is the recent link to one such article.

JMeter for Flex

Commercial Tools

Silk Performer by Borland

Silk Performer is the first tool to provide AMF (Action Message Format) support. Below links provide reference to SilkPerformer feature set and Performance Testing approach using Silk Performer.

Silk Performer Index

NeoLoad by Neotys

NeoLoad is one among the first tools to support the flex-amf3. Below link provide details on the NeoLoad’s support for flex and its features.

NeoLoad Features

WebLOAD by RadView

Like other commercial tools, WebLOAD release an add-in with its professional edition to support flex.

Power of WebLOAD to Adobe Flex

All the tools, Open Source or Commercial have their own features set. LoadRunner is the most widely used industry standard tool, followed by Silk Performer. These two tools have a very extensive support available for all application types testing, monitoring & profiling. With their every new release, these tools enhance their support for most of the new technologies & applications available in the industry. However, tools like NeoLoad has their own advantages with its much sophisticated support for certain application types. Example, for technologies like flex, NeoLoad provides an ease in creating scripts & support for Remote Messages, Polling and Streaming.

Common Problems & Solutions

This section, lists the common problems & solutions that performance engineers come across when testing flex applications. Most of the solutions are provided by the tool vendor.

• Problem

Overlapped transmission error occurs when a flex script is run for the first time from controller. But the same script works fine in VuGen.

Error -27740: Overlapped transmission of request to “www.url.com” for URL “http://www.url.com/ProdApp/” failed: WSA_IO_PENDING.

Solution

The transmission of data to the server failed. It could be a network, router, or server problem. The word Overlapped refers to the way LoadRunner sends data in order to get a Web Page Breakdown. To resolve this problem, add the following statement to the beginning of the script to disable the breakdown of the “First Buffer” into server and network time.

web_set_sockets_option(“OVERLAPPED_SEND”, “0″);

LoadRunner TNT Link

• Problem

During script replay Vugen crashes due to mmdrv error.

mmdrv has encountered a problem and needs to close. Additional details

Error: mmdrv.exe caused an Microsoft C++ Exception in module kernel32.dll at 001B:7C81EB33, RaiseException()+0082 byte(s)

Solution

The cause of this issue is unknown. HP released a patch that can be downloaded from their site.

• Problem

AMF error: Failed to find request and response

Solution

LoadRunner web protocol has a mechanism to prevent large body requests to appear in the action files, by having the body in the lrw_custom_body.h. In AMF and Flex protocol, LR cannot handle these values and fails to generate the steps.

Follow these steps to fix the problem:

1. Go to the "generation log"

2. Search for the highest value for "Content-Length"

3. Go to <LoadRunner installation folder>/config

4. Open vugen.ini

5. Add the following:

[WebRecorder]

BodySize=<size found in step (2)>

6. Regenerate the script

• Problem

There are duplicate AMF calls in the recording log as well as in the generated code.

Solution

Capture level may be set to Socket and WinInet, make sure under Recording Options –> Network –> Port Mapping –> Capture level is set to WinInet (only)

• Problem

A Flex script which has Flex_AMF and Flex_RTMP calls, on replay will have mismatch in the tree view between the request and the response. After looking in the replay log we can see that correct calls are being made but they are being displayed incorrectly in the tree view (only the replay in tree view is incorrect). Sometimes it shows the previous or next Flex_AMF call in the tree view in place of the Flex_RTMP call.

Solution

This issue has been identified as a bug by R&D in LR 9.51 and LR 9.52. R&D issued a new flexreplay.dll which resolved the issue and will be included in the next Service Pack.

• Problem

Flex protocol script fails with “Error: Encoding of AMF message failed” or "Error: Decoding of AMF message failed"

Solution

The cause for this error is the presence of special characters (&gt, &lt, &amp etc…) in the flex request. Send the request enclosed in CDATA

Example: <firmName>XXXXXXX &amp; CO. INC.</firmName> in script to

<firmName><![CDATA[XXXXXXXXXXXX &amp; CO. INC.]]></firmName>

• Problem

When creating a Multi Protocol Script that contains FLEX and WEB protocols sometimes VuGen closes automatically without any warning/error message displayed. This happens when the Web protocol is set to be in HTML Mode. When in URL mode the crash does not occur. There is no error code except a generic Windows message stating the VuGen needs to close.

Solution

This issue can be seen on Machines that are running on Windows XP, and using Mfc80.dll. Refer to Microsoft KB Article in the link below that provides a solution for the same. Microsoft released a hot fix for Windows specific issue that can cause VuGen to close.

http://support.microsoft.com/kb/961894

• Problem

When recording a FLEX script, RTMP calls are not being captured correctly so the corresponding FLEX_RTMP_Connect functions are not generated in the script.

Solution

First set the Port Mapping (Choose Recording options –> Network –> Port Mapping –> set Capture Level to ‘Socket level and WinINet level data’) set to ‘Socket level and if this doesn’t help, follow the next step.

Record a FLEX + Winsock script. In Port mapping section, Set the Send-Receive buffer size threshold to 1500 under the options. Create a new entry and select Service ID as SOCKET, enter the Port (such as 2037 or whatever port the FLEX application is using for connection), Connection Type as Plain, Record Type as Proxy, and Target Server can be the default value(Any Server).

• Problem

Replaying a Flex script containing a flex_rtmp_send() that has an XML argument string may result in the mmdrv process crashing with a failure in a Microsoft DLL.

Solution

The VuGen script generation functionality does not handle the XML parameter string within the function correctly. This results in the mmdrv process crashing during replay. If you have the 9.51 version, installing a specific patch (flex9.51rup.zip) or service pack 2 will resolve the problem

Performance Improvement Recommendations

When it comes to performance improvement of an application, our first concern would be to enhance the scalability for a specified hardware & software configuration.

In case of flex, the scalability issues derive from the fact that BlazeDS is deployed in a conventional Java Servlet container, and performance/scalability of BlazeDS also depends on the number of concurrent connections supported by the server such as Tomcat, WebSphere, WebLogic et al. BlazeDS runs in a servlet container, which maintains a thread pool. Each thread is assigned to client request and returns to a reusable pool after the request is processed. When a particular client request uses a thread for a longer duration, the thread is being locked by that corresponding client till the request is processed. So the number of the concurrent users in BlazeDS depends on the number of threads a particular servlet container can hold.

While BlazeDS is preconfigured with just 10 simultaneous connections, it can be increased to several hundred, and the actual number depends on the server’s threading configuration, CPU and the size of its JVM heap memory. This number can also be affected by the number of messages processed by server in the unit of time and size of the messages. Tomcat or WebSphere can support upto several hundred of users, and any servlet container that supports Servlets 3.0, BlazeDS can be used in the more demanding applications that require support of thousands concurrent users.

References

Adobe Live Docs

HP Support knowledge base for LoadRunner

LoadRunner Reference guides

Farata Systems Documentation