Web Application Performance Analysis Based on Component Load Testing

Transcription

1 Web Application Performance Analysis Based on Component Load Testing Charu Babbar, Neha Bajpai Centre for Development of Advanced Computing,Noida Abstract Performance of many web sites depends on the load on the site at peak time under varying conditions. Performance testing is normally conducted in a reasonably simulated environment with the help of performance testing tools. However, performance of a website depends on various parameters and each parameter must be tested under varying stress levels. It is not possible to draw a common denominator for performance parameters to test the websites due to complexity of websites. Different parts of the websites must be tested with different parameters under varying condition and stress level. In such circumstances, it is necessary to decompose the websites into many components, which represents the behavior of various business components. These business components are mapped to various objects that truly represents the behavior and structure of the part of the website. This paper addresses the new testing process, which uses the concept of decomposing the behavior of the web application into testable objects. These testable objects are subjected to performance testing under varied performance parameters and stress levels. 1. Introduction Load tests checks the capability of the application to function properly under expected normal production conditions and measure the response time. Performance tests are used to evaluate and understand the application s scalability. Performance testing is a type of testing that is performed, from one perspective, to determine how fast some abstract of a system performs under a particular workload.[1] It can also serve to validate and verify other quality attributes of the system, such as scalability, reliability and resource usage. It can measure what parts of the system or workload cause the system to perform badly. The existing Load and performance tools are mainly used to check the performance of CPU load for the entire web application. There is no such tool to confirm the time taken to load the individual components and the total time for the complete application. The individual components may include the images and the files. All these issues results in the need of an efficient web based Load and Performance testing tool for testing website and any web application with individual components performance. 2. Performance Testing Modern computer systems are becoming more complex and dependent on many factors such as the network technologies on the internet. Computing is distributed between various processors such as in the client server paradigm or clients and web servers. Deploying applications that rely on web servers, intranets and client server technologies is a challenge both in assuring that the functionality will be maintained and in guaranteeing that the functionality will be delivered with an acceptable performance. Performance problems can bring all sorts of undesired consequences, including financials and sales loss, decreased productivity. Performance prediction may be accomplished through performance models. Performance testing is directly reflecting the behavior of the complete website. Visitors expect the fast response within a short period of time. Therefore, a rigorous performance testing must be carried out on each site. Performance testing can be viewed as a Black Box testing, which focuses on application and system behavior from outside, with no knowledge of the program code that supports the system. The main objectives of the performance testing are: Maximum number of concurrent users that can be supported while offering acceptable performance. 211 IJTAS 22

2 Maximum number of concurrent users that can be supported prior to causing the system failure. Location of bottlenecks within the application architecture. Impact of software or hardware change on the overall performance of the application. Scalability issues. The performance testing is done by recording or scripting the actions that real users perform, and then playing those actions back against the System Under Test (SUT), in an automated and controlled manner. Performance testing also depends on certain issues like graphics load time and connection methods. 2.1 Setting Performance goals Performance goals will differ depending on the application technology and purpose of application however they should always include some of the following: Concurrency/Throughput If an application identifies end-users by some form of login procedure then a concurrency goal is highly desirable. By definition, this is the largest number of concurrent application users that the application expected to support at any given moment. The workflow of the scripted transaction may impact true application concurrency especially if the iterative part contains the Login/Logout activity. If the application has no concept of end-users then the performance goal is likely to be based on maximum throughput or transaction. Server Response Time This refers to the time taken for one application node to the request of another. A simple example is HTTP GET request from browser client to web server in terms of response time which is measured by load testing tools. It may be relevant to set server response time goals between all nodes of the application landscape. Render Response Time To measure render response time it is generally necessary to include functional test scripts as part of the performance test scenario which is a feature not offered by many load testing tools. [2] 2.2 Prerequisites for Performance Testing The performance testing environment should not be clubbed with user acceptance testing environment (UAT). This is dangerous as if an UAT or integration testing or other testing is going on the same environment, then the results obtained from the performance testing may not be reliable. So, it is always advisable to have a separate performance testing environment resembling the production environment as much as possible. 2.3 Myths of Performance Testing Some of the very common myths of Performance Testing are given below: Performance Testing [1] is done to break the system. Stress Testing is done to understand the break point of the system. Otherwise normal load testing is generally done to understand the behavior of the application under the expected user load. Depending on other requirements, such as expectation of spike load, continued load for an extended period of time would demand spike, endurance soak or stress testing. Performance Testing should only be done to break the system. Performance testing can also be done while the initial development of the application is taking place. This kind of approach is known as the Early Performance Testing. This approach would ensure a holistic development of the application keeping the performance parameters in mind. Thus the finding of a performance bug just before the release of the application and the cost involved in rectifying the bug is reduced to a great extent. Performance Testing only involves creation of scripts and any application changes would cause simple refactoring scripts. Scripting itself although important, is only one of the components of the performance testing. The major challenge for any performance tester is to determine the type of tests needed to execute and analyzing the various performance counters to determine the performance bottleneck. 211 IJTAS 23

3 The other segment of the myth concerning the change in application would result only in little refactoring in the scripts is also untrue as any form of change on the UI especially in theweb protocol would entail complete redevelopment of the scripts from scratch. 3. Web Testing Conventional application software testing is well defined with a set of methods and established over the years. Each method is implemented with a proper strategy. However, one can use some heuristics to test the specific parts, which cannot be done by the available methods due to many practical aspects of the software. But, the conventional methods may not walk with the web based applications. These applications vary with functionality, presentation, and target users. Thus web applications are dynamic in nature and require strong testing methodology. During testing of the web applications, many issues must be addressed as the website is subjected to many uncertainities. 4. Aspects of Performance Testing Several aspects that can affect the Performance includes the following: High activity and volume at launch. Time of the day. Activity spikes due to marketing promotions. Bottlenecks due to hundreds of users on a network. Download time. Usage pattern. Think Time. User arrival rates. Client platforms. Internet access speed. 5. Types of Performance Testing The size of each page and the number of images used on the websites can also affect the performance of the application. It can be divided into three parts: (1) Scalability testing (2) Load testing (3) Stress testing Scalability testing: Scalability concerns the website s ability to handle the volumes and types of activities that can occur after launch. Load testing: The purpose of Load testing is to model real world experiences, typically by generating many simultaneous users accessing the website. Automation increases the ability to conduct a valid load test, because we can emulate thousand s of users by sending simultaneous request to the application or the server. In order to create adequate load and scripts the tester uses information from daily usage logs to mimic a realistic user load. Stress Testing: stress testing is a form of testing that is used to determine the stability of a given system or entity. It involves testing beyond normal operational capacity, often to a breaking point, in order to observe the results. Stress testing may be contrasted with load testing: Load testing examines the entire environment and database, while measuring the response time, whereas stress testing focuses on identified transactions, pushing to a level so as to break transactions or systems. During stress testing, if transactions are selectively stressed, the database may not experience much load, but the transactions are heavily stressed. On the other hand, during load testing the database experiences a heavy load, while some transactions may not be stressed. System stress testing, also known as stress testing, is loading the concurrent users over and beyond the level that the system can handle, so it breaks at the weakest link within the entire system. 211 IJTAS 24

4 Occurrence for Load test: Load testing must be carefully planned to successfully complete the load test the first time, thus shortening the amount of test time. In reality, even with the best planning, load testing may need to be repeated at least once, and usage more time than initially thought due to the time necessary to setup the load test. Some important points for occurring of the load test are: (1) Understand the load requirements of the system. Investigate the total and concurrent number of users the website may need to support. Newly released applications will not have history statistics available. The test team may have to rely on the requirement specification to collect specific targets, such as : i. Number of users in either unique hits per day, per week, or per month; ii. Total concurrent users : worst case scenario at peak time ; iii. Peak request rate : number of pages to be served per second. (2) Identify the tools, such as test tools and monitoring tools, to be used to conduct the load test (3) Generate enough users and transactions to access capacity and performance that will hold up to a live environment. (4) Establish a baseline: create scripts to simulate a single user with single browser. (5) Create test scripts to simulate multiple session played on multiple browsers. (6) Identify any other applications that are running on the application server to capture the correct system activity. (7) Execute the test(s) multiple times. (8) Identify the players who will be monitoring the system performance during the test. (9) Conduct formal inspections on the test scripts. 6. Parameters of Performance: Some of the parameters which affects the performance of web pages and websites are as below: 6.1 Parameters for Performance Testing: Response time during data retrieval. Calculations. Turnaround time. Bandwidth. Webpage load time during multiple user logins. Capacity. Volume. Load 6.2 Time Parameters for Performance Testing: Elapsed time Response time Hits per second Throughput Page download time Transaction per second Request Response 7. Approach for testing components of the Web Application The problem discussed above in introduction required the component based performance testing tool. Performance testing of components of a web application aims to evaluate the response time, utilization, and throughputs, as a function of the system description and workload parameters. The existing load and performance tools a mainly used to check the performance of CPU load for the entire web application. There are no such tools to confirm the total 211 IJTAS 25

5 time taken to load the complete application and also individual components. The individual components may include the images and the files.figure 1:Proposed Framework 7. Implementation The proposed approach discussed above has been implemented with the objective of calculating total number of components in a web page along with the load time taken by each component. 7.1 Input to the Browser Window E:/JProject/Testingproject/src/testingproject/training_en.html, E:/JProject/Testingproject/src/testingproject/perftest.html and E:/JProject/Testingproject/src/testingproject/html_codes_chart.html Formulas have been used to find the request time, response time and load time of various components of the web application : Request time= time measured when web application is start loaded. 211 IJTAS 26

6 Response time=time measured when web application is completely loaded. Load time = Response time-request time Following code is used for finding the load time of a web application: HttpWebRequest request = (HttpWebRequest)WebRequest.Create(address); System.Diagnostics.Stopwatch timer = new Stopwatch(); timer.start(); HttpWebResponse response = (HttpWebResponse)request.GetResponse(); timer.stop(); TimeSpan timetaken = timer.elapsed; Results Achieved: Table 1: For Image Component Url no. Url Request time No. of images Response time 1. Training_en.html Perftest.html Html_codes_chart.html Table 2: For Html page Component Url no. Url Request time No. of Html pages Response time 1. Training_en.html Perftest.html Html_codes_chart.html Load time Load time Table 3: For Css Sheets Component Url no. Url Request time No. of Css sheets Response time 1. Training_en.html Perftest.html Html_codes_chart.html Load time 8. Benefits of Proposed Solution 1. Measures can be obtained for the users' effectiveness, efficiency and satisfaction. 2. Reports generated are useful for checking particular component performance. 3. A user-friendly interface based on point-and-click operations tremendously lowers the learning curve. 4. Does not require a programming background. For those users who wish to use their programming skills. 9. Conclusion Web based applications are more complex compare to the conventional client-server applications due to many unknowns and uncertainties. Among many complexities, performance testing is one of the difficult activities which has to be tackled with more vigor and aggression. 211 IJTAS 27

7 Performance testing, which enhances the customer confidence on the web applications, is based on many approaches and strategies. Testing the site as a whole is cumbersome and tedious due to many complexities including the behavior. The sub-behaviors like, aquery, downloadable objects and meaningful business entities are mapped on the web application by properly organizing the application. The behavior of each component, which is available in all performance testing tools. The scenario is then for a specific test session for different stress levels. This methodical approach not only ensures the structured way of testing but also provides step by step enhancement of the quality of the site. Experimental results shows that the whole web application need not be subjected to rigorous performance testing with all performance indicators set for each sub behavior. The proposed idea will be helpful as it will provide the complete loading information about every component used in the application like request time, response time, load time, etc. Acknowledgement The author sincerely thank to Mrs. Neha Bajpai(Project guide) and to friend who helped me in conducting the approach and calculating the results during performance analysis. REFERENCES [1] Rick Potts, Monitorin and analyzing a load test result,microsoft Corporation, September 26. [2] Herrlich And Ramuschkat, Flex Data Services Performance Tests Version 1.,Sven Ramuschkat,Dirk Eismann, January 19th 27. [3] Gary B.Ackerman and Neal Stouhton, Simulation _based load synthesis methodology for evaluating load _management programs,ieee Transaction Power Appratus And Systems, Vol. Pas-1, No. 4, April 23. [4] Osama Hamed And Nedal Kafri, Performance testing for web based application architectures, ANSS, 4th Annual Simulation Symposium,(ANSS 7), PP.3-1, 28. [5] Kavitha KarthikK Subbiah, Comparative stusy of rational and mercury functional testing tools, Division Of Computing,Studies Arizona State University, Polytechnic. [6] Qinglin Wu, Performance testing and optimization of j2ee-based web applications, Second International Workshop On Education Technology And Computer Science,IEEE,PP ,21. [7] Daniel A. Menasce, Load testing of websites, IEEE Internet Computing,PP.7-74, July-August 22. [8] Steven Haines Senior, Performance testing methodology,october 25. [9]J.D. Meier,Carlos Farre A Hantbansod,Scott Barber And Dennisrea, Performance testing guidance for web applications,world Academy Of Science, Engineering And Technology,25. [1]Daniel, A. Menasce And George Mason, Scaling the web load testing of websites,july - August 22. [11]B.M. Subraya And S.V. Subrahmanya, Object driven performance testing of web applications, May 3 - JuneE 2, 2. [12] Charu Babbar,Neha Bajpai And Dipti Kapoor Sarmah, A survey on evaluating performance of web application performance,4th November,21. CHARU BABBAR completed M.Sc (C.S.E.) from Guru Jambheshwar University,Hisar in 27 and has 2 yrs. Industrial experience. Now Currently pursuing M.Tech(I.T.) from CDAC-Noida and working on project based on Software Testing. The area of interests are in the subjects related to Software engineering and Software Testing. She has published and presented 1 research paper in international conference. Mrs. NEHA BAJPAI received M.Tech in Information Technology from the Vinayaka Mission University of Tamilnadu in the year 25. She has nine years of teaching and one year of IT implementation experience. Presently, she is working as a Senior Faculty in School of IT at Centre for Development of Advanced Computing (CDAC), Noida. Her present interests are in the subjects related to Object Oriented Analysis & Design, UML, Software Testing, Object Oriented Technologies (Java Programming) and Object Oriented Database Management System. She has worked on various projects in her ten years of teaching and software implementation time span. She has over 1 research papers out of which three are in international journals and rests are in international and national Conferences & Seminars. She also served, coordinated and taught various International Training Programs under Indo-Vietnam bi-lateral Cooperation and ITEC/SCAAP Scheme of MEA. 211 IJTAS 28