I want to analyse the siege output. I am doing that, when i run the siege , I am checking at exact what time the siege tool getting failing. Failed transaction should not be zero, note that how many number of transactions were hit, I want to know how to calculate the concurrency , response time, throughput, transaction rate ? I dont't understand from siege documentation, In the output, which should I more need to check? I am running siege like put different parameter values and checking how many transaction hit were occured.

How to identify the result of concurrency ? 1 sec - 90 hit, 8 sec--10 hit, so how to get the concurent result ? How to calculate the concurrency here

Siege version is : SIEGE 4.0.2 and ubuntu 16.04 and no other problem like dos ...

siege -c25 -t15s

    Lifting the server siege...
Transactions:               1146 hits
Availability:             100.00 %
Elapsed time:              14.17 secs
Data transferred:           0.90 MB
Response time:              0.06 secs
Transaction rate:          80.88 trans/sec
Throughput:             0.06 MB/sec
Concurrency:                4.76

siege -c50 -t10s http://
Transcation : 1946,   concurrency : 0.23

    siege -c50 -t20s http://
    transaction : 3842, concurrency : 0.22

    siege -c100 -t2m http://
    Transaction: 47508,   concurrency : 0.35

siege -c150 -t3m
Transaction : 104724, Concurrency : 3.83

siege -c100 -t3m
Transactions: 70363 hits, Concurrency :   2.46

siege -c255 -t5m  http://8080/start
Transaction : 302924,  Concurrency :  2.22

So, i need to make that when i test the load with -c option value and siege concurrency output value should be approximately equals, if not some problem in server. May I know my assumption is correct ? and How to identify the what the real problem ?

Is it possible If I need to understand siege with a GUI graph. What should I do ?

  • Too many questions, without context. Why do you want to calculate concurrency. Why do you expect successful transactions in 1 0.59 seconds? Probably the calls were still busy. Why does your command not match your output? 3 minutes vs 1 second. Maybe try on your own website, one you control. With realistic inputs. Let say 10 users, default delay, for a couple of minutes and then check the results. Jul 5 '17 at 7:39
  • Why two times -t? Why the delay? I updated my answer with a small test. Seems to work fine here on our network. Which version are you using? I saw you was using github.com as a test-website earlier, they might have DDOS protection. Jul 5 '17 at 8:23
  • Sounds like your webserver cannot handle the traffic. This is expected in load-testing. You send 50 users, only for 20 users you get the result. Find a system-admin and a developer and analyse the server, application, logs and your results, until you understand what is going on. This is not a tester thing, you should just signal the server+application behave unexpectedly. Jul 5 '17 at 10:38

Seems the tool records it and displays it in the output: Concurrency:50.92 The answers seems to be to run the load-test with your settings and record the concurrency instead of calculating it.

A load test of one second does not make sense. You want to measure load over a longer period of time. The thing with the short period is that if the page is slower than 1 second you will loose some results. Also the ramp-up of the tool might not reach all the wanted users in 1 second. 1 second is just too short.

In a longer run I would expect the concurrency number to exactly match the -c options number. If this is not the case I would ask direct question at the developers or look at the code as it is open-source.

“Truth can only be found in one place: the code.” ― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship

My test with Siege 4.0.2 on a clean Ubuntu Server 17.04 with VirtualBox 5.1:

enter image description here

As you can see the output seems to be correct, just like I expected. Somethings to check:

  • Firewalls and network configuration might be blocking traffic. Check OS, Modems, etc...
  • Website you are testing on has Denial of Service protection
  • Version of Siege is out-of-date or has bugs

I would first test your Siege with a small webserver on the localnetwork. Just a simple http-server with a HelloWorld! index.html. Just to see the chain is working. Then start experimenting with web-servers on other networks.

  • You should not edit questions and suddenly ask extra or new questions. This is not how this platform works. Also it does NOT motivate me to answer your questions. :) Jul 6 '17 at 12:10
  • Deleting your older comments is also unhandy. Jul 6 '17 at 12:11
  • I am also wondering why you use Siege if you cannot figure out how to use it. Maybe it is better to use a common load-test tool like jMeter as it is better documented. More people use it, so more people to answer your questions. Also it has the features you are looking for out of the box, e.g. visual reporting: jmeter.apache.org/usermanual/generating-dashboard.html Using a lightweight load-test tool noone really uses means you are on your own. I am not putting more effort in trying to understand and explain Siege for you. Got other work todo. Jul 6 '17 at 12:13
  • I can't my project manager asked me to test with siege tool
    – user24314
    Jul 6 '17 at 12:19
  • Lol, maybe the project manager can explain to you how to use it, certainly cause he/she also want GUI reports probably, or not? Really, it is possible that you give feedback that another tool or strategy might be much better. It is called being proactive. :) Asking is not forcing. Maybe you want to understand why he/she want you to use Siege and see if other tools offer the same. E.g. like open-source or easy-to-use. What are his or her assumptions with this tool, why is it so good? Hopefully not someone else telling it is a good tool. Goodluck :) Jul 6 '17 at 12:55