Siege - running a stress test benchmark

Question

I need to do a benchmark test of a HTTPS server using Siege, to see how it behaves under massive load. I'm initiating tests from another machine which is quite powerful and it is connected to the same physical switch the server is connected on.

But when I initiate a test, I can't get it to make more than 170 requests per second. With this load the server's CPU usage is at 15-20% and the average response time for a request is approx. 0.03 seconds. Load of the client machine is approx. at 10%.

So, I gradually increase the number of users in Siege (the number of worker threads) and request rate linearly increases up to 170 reqs/sec, but it never gets over it. No matter how many more worker threads I start, the load on the server is never more than 20% (and the client's load also doesn't increase any more).

How can I overcome this?

I've googled a bit and found out that after a request is completed, a socket associated with one ephermal port remains in WAIT_TIME state for some time during which it can't be reused. I tried to overcome this by doing these things:

sysctl -w net.ipv4.ip_local_port_range="1024 65535"
echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle

Oh, and the client machine is a Linux (RedHat, I think, but I'm not sure). Any help would be appreciated.

Are you sure you aren't CPU-bound on the host running siege? Sounds like something is bottlenecking it. — Peter, Aug 19 '14 at 15:24
No... 8 cores, all below 20%, most below 10%. Something else is causing the problem. — morgoth84, Aug 19 '14 at 16:06

score 0 · Answer 1 · answered Aug 21 '14 at 08:46

0

Have you considered other tools apart from siege? As per Open Source Load Testing Tools: Which One Should You Use? Tsung and Apache JMeter seem to be producing higher request rates on less powerful environments.

Going forward siege may be not enough to create a realistic load test as hammering one or several URLs isn't something which happens to servers in the real world.

answered Aug 21 '14 at 08:46

Dmitri T

531
2
2

Hi. Thanks for the suggestion, but I found out it was an internal problem of the server i was testing itself, not a problem with siege or the client machine. – morgoth84 Aug 26 '14 at 08:46

score 0 · Accepted Answer · answered Aug 26 '14 at 08:49

0

It turned out to be a problem with the server I was testing. Thanks to all that wanted to help.

answered Aug 26 '14 at 08:49

morgoth84

161
1
1
7

Siege - running a stress test benchmark

2 Answers2