Introduction To Web Application Load Testing
Introduction To Web Application Load Testing
(1)
(2)
Profiling: Examine a single software application CPU and s memory usage. Result: Detect most significant performance problem in software application and remove it.
(3)
Load testing: Measure the applications ability to sustain a number of simultaneous users and/or transactions with adequate response times. Result: changes to hardware, software infrastructure, or application design
(5)
Warning!
Capacity load testing is a denial-of-service attack! When testing across network, you must: Think through impact on network and other users of performing test Notify and obtain permission from network administrators or ISPs Schedule test for off-hours Failure to observe appropriate netiquette can lead to reprisals. Do NOT: Capacity load test using katrina or ICS lab machines!
(6)
My web application is slow. Should I: Add RAM? Move from Windows to Linux? Optimize my application code? Allocate more memory to the JVM? Move from Tomcat to Resin? To Apache? Move the database to its own server? Change the database indexing? Move from InstantDB to Oracle? Upgrade my Internet bandwidth? Use Enterprise Java Beans?
(7)
(9)
Internet
(10)
Six variables impact on performance: Internet bandwidth (T-1, 56K modem, etc.) Server hardware configuration (RAM, Disk speed, OS) Web server software (Tomcat vs Resin, etc.) Database server software (InstantDB, db40, etc.) Application design (caching, algorithms, etc.) Database design (indexes, tables, queries)
Internet
LAN
LAN
10 variables impact on performance: Internet bandwidth Web server hardware, software, app design App server hardware, software, app design DB server hardware, software, DB design
(11)
DB Servers
(12)
(13)
(15)
(16)
Network problems
Requires specialized testing to uncover (must stress network without causing application/db stress). Potential sources of network problems: Firewall throughput Internet access throughput Load balancers, gateways, routers
(18)
(19)
(21)
(22)
Initial screen
(23)
(24)
(25)
(26)
(27)
(28)
(29)
(30)
10
(31)
(32)
(Representative)
(33)
11
(34)
(Representative)
(35)
Conclusions
With 10 threads at rate of 1 page/second, Response time averages 5 seconds. Server CPU utilization at around 30% Web server process requires 25MB. Load test methodology problems: Web server used for other web apps Did not vary search term, session ID. Stress testing (12-24 hr) not performed Capacity testing not performed. No checking for correct page response as load increased. Next steps: Check server under stress testing conditions. Fix methodology problems. Repeat with alternative hardware, software.
(36)
12
JMeter Tips
Use 1.6.1 for now. (I had problems w/1.7b) Make sure you load your .jmx file inside of Test Plan, otherwise it isn executed. t Possible additions to jmeter.bat java cmd: s -Xms64m Xmx128m (increase memory) -Dsun.java2d.noddraw (eliminate GUI flicker) When entering a field value in GUI, make sure to exit field so that value is seen!
(37)
(38)
Summary
(39)
13
Keep it in perspective
Functional correctness is more important than non-functional correctness. Not every WebApp requires scalability. High volume web sites require professional load testing.
(41)
14