There are many tools to use for web performance testing, but if you want a good tool that does the job, I recommend Jmeter. The good and bad thing about JMeter is that there are alot of different options and features. To make it simpler for you, the good folks at Digital Ocean have a good tutorial on getting it set up, here: How To Use Apache JMeter To Perform Load Testing on a Web Server | DigitalOcean. While this is fine for testing one page, there are test scenarios where you want to have the user perform multiple steps (e.g. go to the home page, login to their account, check their account balance, then logout). If that is the case for you, too, then you want to read this next: How To Use JMeter To Record Test Scenarios | DigitalOcean (I used Firefox for this: if you are going to use JMeter to develop your performance test cases, then download Firefox too.) For any performance testing that follows a sequence, you really want to use the recording feature of JMeter.
Some other thoughts….
On my thread group, I added the following listeners:
- Response time graph
- Graph results
- Aggregate report
- View results tree (with scroll automatically on)
I also login to the web server and tail -f the access log (and sometimes the error log).
I do all this because it is easy to run have a lot of errors when you first (and even later) run your test. For example, if you are testing a sequence, you might see good performance, but you might also see 404s in the access log, or you might see other anomalies in the aggregate report (e.g. good response 90% of the time, but bad response on average). Having more data is better and it insures you don’t have false positives (e.g., you think performance is good, but it really isn’t because the application is failing).
As soon as your developers have some code in place, have someone run Jmeter against it. Don’t wait until towards the end of the project. Jmeter is free and anyone can use it.
Back up your test plans often. It is easy to change your test plan, have it go from a successful one to an unsuccessful one because of the change, and then find it hard to go back because you changed a number of variables.
For your test plan, have multiple thread groups. This will allow you to test different test scenarios for different test groups. You can have different test plans too: it’s up to you how you manage it. For example, I recorded a long sequence for one test group, then I copied it and made a simple test group with less steps by removing them.
Smart People I Know 
Thanks for sharing, however I would recommend the following:
1. Run your test in command-line non-GUI mode as JMeter GUI is designed only for tests development and debugging, it will be the bottleneck when it comes to high loads
2. Remove all the listeners from your Test Plan, especially the View Results Tree as it is very memory intensive
See 9 Easy Solutions for a JMeter Load Test “Out of Memory” Failure article for more information on tuning JMeter
Those are great additions! Thanks!
https://loadimpact.com/ cloud service to help you do load testing.
Though load testing is important, functional tests using tools like Selenium Grid (the older versions of Selenium are no longer up to snuff keeping up with the browser joneses) will make sure everything still functions correctly. As a bonus you can also check if your tests become slower or faster over time with more scenarios as a part of a build.
Another tool I use for functional testing and farming is Sikuli which is useful for applications that have accessibility as an afterthought (Selenium utilizes the accessibility features), Sikuli uses what appears on the screen.