The key goals of load testing are:

1. Find out whether your website can support the expected # of concurrent users.
2. At what load does the app break?

To do that, you normally follow these steps:

1. Identifying the primary user path
2. Identifying the expected # of concurrent users. (Both now and future)
3. Set up virtual users to hit the app (load generation capability is the key factor to pick the right tool. You don't want too much hardware investment to generate the load you want, right? )
4. Run the test
5. Analyze the result (throughput under load, avg response time under load)

Challenges to load test Flex app

We have a web application that has Flex frontend talks to J2EE web application backend via AMF. How do we load and stress test this system? We certainly can just perform load test against our backend. However, it may need to expose our service via Servlet and load test it as typical restful web service. If we want to simulate Flex and load test through AMF. We need to find a way to capture the AMF requests from Flex client and replay it in our load testing suite. To do that, we can use Charles http proxy to capture the AMF request and tell JMeter to load test our application via replaying this AMF request. This  article can give us the detail. However, Charles is a commerical product. If you want a free solution, you can try this.

I know that JMeter comes with proxy to record the request. You can try it out to see whether you can exam the AMF message. Let me know if it works!

JMeter

Load is all of the users using your web site at a point in time. Load includes users making requests to your web site as well as those reading pages from previous requests. However, we do need some way of differentiating between all clients and those clients actually making requests to our web site. We use the terms concurrent load and active load (making request) to make this distinction. We use the JMeter to help us to generate the load to our system. In term of load generation, we should make sure that we can simulate the peak load. JMeter is a great load testing tool. I have heard that Google is using this to load and stress test its application.

To use JMeter, follow the steps below:

1. Set up Thread Group - use to model concurrent virtual users and decide how you want the load be generated.
   • Number of threads.
   • The ramp-up period (it tells JMeter the amount of time for creating the total number of threads). At the beginning of a load test, if the ramp-up period is zero, JMeter will create all the threads at once and send out requests immediately, thus potentially saturating the server and, more importantly, deceivingly increasing the load. That is, the server could become overloaded, not because the average hit rate is high, but because you send all the threads' first requests simultaneously, causing an unusual initial peak hit rate. The rule of thumb for determining a reasonable ramp-up period is to keep the initial hit rate close to the average hit rate.
   • The number of times to execute the test.
   • If the client machine running JMeter lacks enough computing power to model a heavy load, JMeter's distributive testing feature allows you to control multiple remote JMeter engines from a single JMeter console.
2. Introduce user think time
3. Specify response-time requirements and validate test results.

To get familiar with it, here are some articles I found it useful

1. Stress testing with JMeter by Daniel Rubio - Linux.com
2. Loading testing with Apache JMeter by Kulvir Singh Bhogal, - Devx.com
3. JMeter distributed testing
4. JMeter recording testing
5. Load test your drupal app scalability with JMeter - Part 1, Part 2
6. Load testing with JMeter - powerpoint - very good!
7. Scalability Factors of JMeter in Performance Testing - response size, response time, protocol, hardware configuration, load generating tool architecture and configuration, complexity of client-side processing.
8. JMeter Tips - Javaworld

 Reference

1. Someone has written a nice article in sys-con to talk about how to load test Flex application.
2. Use FlexUnit for stress testing
3. Test Remote Data Service via FlexUnit
4. Load testing with log replay - interesting idea