We have a single JMeter HTTP load generator that we use to capacity test our web service (running Django + mod-wsgi + Apache)? If we want to modify the traffic generated to DoS our web service, what are the most effective changes that we can make that could cause the target service to fail with the lowest resource requirement on the load generator?

Examples that we are considering include slowing down the traffic send rate, pulsing requests to be sent in bursts and sending malformed data. Which of these, or any others, will yield the most bang-for-our-buck, considering our tech stack?

1 Answer 1


Denial of service and traffic overload are two different things, so using a traffic generator isn't really the way to go. Traffic generators are great to model real-world usage of a resource (e.g. users coming at random times (Poisson distribution), random or recorded navigation templates, common searches and errors...). Most DDoSes are little more than GET / HTTP/1.0, but in job lots. Large job lots. That's not real "traffic".

If you want to see what happens when the system gets DoSed and exhausts its resources, you can e.g. disable SYN half-open protection (SYN cookies) if present, and use some DoS utility to fake opening connections. Or keep the connection open through, say, a Perl script.

Or you can send requests to those endpoints with a higher system load (e.g. that need database querying).

Malformed data will in all likelihood be intercepted at the outer layers of the Django router (if not by WSGI itself) and generate the least load. It depends on the malformation, of course.

Slowing down the send rate should stress Apache more than the rest of the stack (Django sends its output in fire-and-forget mode), while pulsing requests should hit Django more heavily, especially if they're crafted against the more expensive endpoints.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .