|
|
| Home xmlfeed submit articles sitemap privacy links contact us terms submission guidelines |
 |
|
|
 |
Introduction: Performance testing has become an integral part of Client/Server and Web environments today. With performance engineering comprising performance testing tools, the testing cycle time can be reduced significantly. The capacity of existing performance testing tools has limitations in supporting various protocols. This white paper indicates that Performance testing tools offering wider coverage without much investment are the need of the hour. The SituationA performance testing tool can simulate internet user behavior only on http protocol and can be enabled for multi protocols as well by plugging-in an ActiveX Component or a Java Class programming language code establishing a TCP/IP Connection within the script of the tool. Common Protocol Support: http https Telnet FTP While with licenses for the http protocol, the compact version of existing performance testing tools can only support the http/https; additional licenses are required to be purchased for supporting other protocol(s). Enabling tool to support other protocols: A particular performance testing tool can be made to support a group of desired protocols by setting up a server / application specific development process. This performance engineering is a complex process involving the following steps Steps involved: 1. Deciding the transactions. 2. Setting up a packet sniffer for capturing the packets traveling between the user machine and the Server. 3. Executing the transactions manually. 4. Saving the details of the captured packets. 5. Analyzing the flow of packets starting from packet 6. Determining the user input in the packets. 7. Parameterizing the user inputs in the packets. 8. Creating functions to simulate the packet flow. 9. Creating an instance for that component inside the script of the tool for plugging-in the component within the tool. 10. Calling functions from the script. Analyzing Packets: Analyzing packets is the major part in the process requiring tedious coding and decoding. Phases in Analyzing: Six phases in the process of analyzing packets - Separating Headers and Data portions in the packet. Analyzing the Header packet. Analyzing the Data packet. Determining the constant and variable bytes in the data specific packet, both are usually in HEX String. Repeating the process with various user inputs getting accustomed with the bytes transferred. Checking if any data for the previous response is transmitted with the next request. Ethereal - Network Protocol Analyzer is very helpful sniffing tool to see new variable bytes by simulating traffic from code detecting several protocols, such as: H323 / Q931 VOIP Protocol. ICQ Protocol. Java RMI. Remote Procedure Call. IEEE 802.11 wireless LAN. Ethereal has a rich display filter language and can view reconstructed stream of a TCP session. Creating the PSEUDO Client: While designing the client, the transaction is divided into stages with separate functions for every user interaction and server reply. Separate functions are required for: Sending the first request and receiving the first response. Extracting data from the response to append in the second request. Sending second request and receiving second response. Similar process must be followed for the remaining traffic. Maximum number of variables must be created for keeping track, with the possible constant fields stored as variables. Following is the screen-shot of an ethereal record of a simple http transaction. Integration: Finally, the client component is integrated in the tool, which requires creating an instance of the component and calling the function with different parameters i.e., user inputs, which allow the desired protocol to be supported by the tool. Process Pros: 1. Perfect simulation with perfect packet analysis. 2. Frequent update for new plug-ins for the new protocols. 3. Cost effective. Process Cons: 1. Difficulty in decoding. 2. For encrypted applications the process cannot be implemented. 3. For Oracle NCA protocol the process can be implemented only if plug-in is readily available. Conclusion: Performance testing can demonstrate the system meeting performance criteria. The later a performance defect is detected, the higher the cost of remediation. This is true in the case of functional testing, but even more so with performance testing, due to the end-to-end nature of its scope. It is always helpful to have a statement of the maximum number of users likely to use the system at peak times. Performance testing almost invariably concludes that it is the software rather than hardware that contributes most to bottlenecks in processing data. View all RTG marketing's articles About the Author: |
|
 |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Extending The Capabilities Of Performance Testing Tools
|
