1

Is there any way to simulate 1000 or so visitors accessing our server? We have undergone a complete app re-write and re-structuring. We had a very optimized Tomcat server, and are moving to a Glassfish back-end server with an Apache front-end.

We are in "beta" phase right now, but only have a few of our users actively using it. We get 30-40k users in a single day (maybe a max of 1000 at any given time). When we go full steam with the new set up, we don't want it to crash or be overburdened at specific bottlenecks.

Basically, is there any testing tools that we can use to simulate a x-amount of calls to specific URLs?

slm
  • 7,355
  • 16
  • 54
  • 72
Tim Withers
  • 125
  • 5
  • Canonical question: http://serverfault.com/questions/350454/how-do-you-do-load-testing-and-capacity-planning-for-web-sites – HTTP500 Jun 22 '13 at 12:43

3 Answers3

1

Start with ab.

There is also httperf.

Finally, take a look at jmeter.

dmourati
  • 24,720
  • 2
  • 40
  • 69
  • I just saw those. Thanks for the info! We tested 5 servers hitting with curl 1000 times, and that seems to do the trick. – Tim Withers Jun 21 '13 at 23:49
1

If you're already using AWS this is a pretty neat solution:

bees with machine guns

http://blog.apps.chicagotribune.com/2010/07/08/bees-with-machine-guns/

What we needed was a solution that allowed us to use multiple, topographically-close clients to all simultaneously assault our servers with traffic.

Bees with machines guns is a fabric script that I put together to aggressively load-test our sites. It provides methods to spin up an army of EC2 instances (the bees), assault a target server with a configurable amount of traffic, and then spin those instances back down.

Community
  • 1
Drew Khoury
  • 4,569
  • 8
  • 26
  • 28
1

Just wanted to give you some pointers when doing your load testing (proper testing will reduce bad news in near future).

What I have experienced is that - when simulating "real" web service users, use "real" tools for it. Such as Selenium, Watir or Robot framework.

Why? Simply put: These tools will simulate actual browsers with everything included, not just few JMeter GET/POST-requests towards your server. I'm also a big fan of JMeter'ish request tests but you have to know the limits. JMeter is great, when you have already discovered some bottle-necks. As I understood, you're not yet sure are there any.

JMeter isn't a real browser, as said in jmeter documentation:

JMeter is not a browser

JMeter is not a browser. As far as web-services and remote services are concerned, JMeter looks like a browser (or rather, multiple browsers); however JMeter does not perform all the actions supported by browsers. In particular, JMeter does not execute the Javascript found in HTML pages. Nor does it render the HTML pages as a browser does (it's possible to view the response as HTML etc, but the timings are not included in any samples, and only one sample in one thread is ever viewed at a time). (source: http://jmeter.apache.org)

Just wanted to point out that sometimes after load testing, you might still find out that system is behaving differently even though we did our proper load testing. Sometimes people tend to forget that user with a browser is doing tons of stuff under the hood and that is also traffic/load from a webserver point of view.

Just saying.

Community
  • 1
tomi
  • 346
  • 1
  • 5