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, 2014 at 15:24
  • No... 8 cores, all below 20%, most below 10%. Something else is causing the problem.
    – morgoth84
    Aug 19, 2014 at 16:06

2 Answers 2


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.

  • 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, 2014 at 8:46

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.