Decades ago we were testing a new system and the company paid users overtime to come in on a weekend to test it. They all hit enter at the same time and the system crashed.
Then they asked me to try to simulate the users with some software that they purchased. So we tried to think through how a real user would access the system. They might come in to the office sign in, do a few things, and go get a cup of coffee or maybe go to the bathroom. Then come back to their desk and work at a somewhat randomized pace depending on when a customer might call for information, or the user might get interrupted with a phone call or something.
We had a number of discussions on "how many concurrent order entry users", "how many concurrent order inquiry users", "how many users accessing other parts of the application", "how may users logged in but doing nothing at any given time", etc. Plus our user base was US centric but spread out from east to west coast. So when west coast users were signing in, east coast users might be going to lunch.
So for whatever load test tool you are using, your "script" should include "think time" and spread out the user logon timeframe over whatever period you expect your users to sign in. Don't just throw thousands of users at your site, you need to consider how an actual human might use the site.
Based on the numbers that you have given, I would suggest starting small, lets say 500 users, and let it run for a while and try to reach some normalization point where you can determine that "this many users" need "this much cpu and memory". Watch the cpu/memory/disk utilization on both the web and database servers.
Then ramp up, go to 750 users. But each time you increment, you need to have your web and database admins look at the performance. What requests are taking the longest time? How efficient is the SQL call? Is the disk subsystem able to keep up with the I/O? How is memory utilization, CPU utilization, where is the bottleneck?
Did you use the '-aon' switches when you ran netstat?