How to do load testing for a website?

Question

I want to do performance testing. But we do not have any requirements. I want to do load testing for a website. How do I perform these tests?

My website is like youtube (social application). In this I want to check how many users can upload video at a specific time, how many videos can we able to store, 10000 videos possible are not? How to test these.

I am currently using JMeter for load testing.

Can you send some suggestions and what are the timings we want to check? How many concurrent users are needed?

Thank you

Answer 1

http://www.loadstorm.com

Is a nice website to get started for load testing.

If you're looking for something more advance try hp loadrunner-

http://www8.hp.com/us/en/software-solutions/software.html?compURI=1175451#.UmbpLZRgY08

Answer 2

But we dont have any requirements.

Building a performance test is a micro scale development effort. Without requirements you will not know what to build into your test, from which business processes to include to how many of each type of user to what are considered acceptable response times. If you are performance testing an update to an existing application then you likely have transactional data (and possibly conversion data) for an existing base of users to draw from. Hopefully this information is historical so you can observe growth over time. Plan for 18 months out for your load, better 36 months out.

You will need the business stakeholder involved in the requirements. This app was built to satisfy a business need and someone will either be demoted, fired, promoted or bonused based upon the success or failure of this deployment. Find that person! Anyone who is going to have a bonus or a position in on the line regarding this application will also likely understand the business needs and expectations very well.

If this is the first time you have engaged in a performance testing effort then you would do yourself well to hire an expert in the field. About 85% of the skills you need are tool agnostic, with that last bit filled in by your tool d'jour for your testing effort. That 85% is critical in the requirements, monitoring, analysis and reporting sections. Being a performance tester is not unlike many other disciplines in the sense that the best development route goes through a confirmation of core skills, formal instruction on processes, methods and tools and then a period of internship. Have you ever seen a haircut by someone unskilled as a barber or a brick wall put up by someone with no masonry training? If so then you understand what value a performance test will have if you have just been dropped into the role.

Hire the experienced lead for the project. Follow them around like a newborn puppy. Take copious notes. Ask lots of questions. Make sure you can maintain what they have developed for future use and understand why items have been developed

Otherwise without requirements you are in danger of heading down the path of an "Art Test." An art test is performance test divorced from requirements and/or observations from production data. You see this in a lot of environments where only a week or two is left at the end for a performance test, subject to no slippage in the project, and without time to fix any issues. In short, it becomes a check off box with low value.

Oh, and check your logs for actual concurrency on the upload. What you may find will surprise and delight you. I have spent many an hour in discussion with someone telling me that their site has 10000 concurrent users on it only to find when looking at the logs that the average session duration was just under ten minutes and the max concurrency in 10 minute blocks was only a couple of hundred users.

Answer 3

Based on my experience of loading test, you might look into these solutions

• http://www.webperformance.com/ We use Web Performance to generate virtual clients, they provide very nice tools, integrated into AWS, so it is fast and cheap which compare to other solutions.
• http://newrelic.com This guy to monitor our server and application, the graph show very detailed information (bottle neck, resources, etc..)

Oh, there is interesting book (http://www.amazon.com/Scalability-Rules-Principles-Scaling-Sites/dp/0321753887) about this issue, and it would be great help.

Answer 4

There are two different questions here:

1. Requirements: what are the statistics you are looking for?
2. Technological: how do you test to see if you meet the goals you set for yourself?

Regarding (1): In a perfect world, you would be able to analyze your target customer scope and understand how many people would be using your system concurrently. You would then understand how many of them would actually trigger a response in your web site (concurrently), and from that understand how many requests you need to handle concurrently.

Another question you would probably want to know, is the size of data you can expect to have. If you have 1,000,000 users, and 1 out of 100 users uploads a video, that would lead to 10,000 videos in your database. So the answer to that one is again dependent on the number of users and their behavior.

It is probably possible to do some kind of a market research and come up with numbers, but lean startup methodology states that you usually don't know the answer to these questions, you only guess, and usually you guess wrong.

So, assuming you can't really know ANYTHING, you should understand how to make your system scalable in a way that would let you support ANY number of concurrent users, and ANY size of data.

But, you probably want to know statistics regarding the current infrastructure you are using. This leads us to (2).

JMeter is a good tool for testing concurrent load, you didn't state what your server is written in, but JMeter suggests Java, in which case on top of everything else you should understand memory limitations and Garbage Collection times.

Assuming a stateless (or at least session-sticky) distributed system, you would want to test a single "typical" server for response time and failure for a given number of concurrent requests. Start small, and go higher as high as the results are still acceptable (i.e., for 100 concurrent requests, 50ms response time and 0 failed responses is acceptable, 1000 concurrent gives you 300ms delay and 5 failed responses, and at 5000 you get to 500ms and 15 failed responses which is as high a delay as you deem acceptable, and as high a number of failures as you can accept)

You would probably want to change "typical" from above and see how different infrastructure gives you different results, the great thing about today's cloud services is that you can easily go to EC2 and get any type of infrastructure for very little investment and test your results so you know what you need to buy (assuming you don't want to stay hosted on EC2). You can also use EC2 to host JMeter instances (I read an article about that once, can't remember where but google it), and you can have many many concurrent requests issued for under 200$/test.