CODEWITHSUNDEEP
linuxjmeterload-testingthroughput
clint
clint

Reputation: 1946

Benchmarks for linux/apache performance on 1000 concurrent requests

I have a linux server of following configuration:

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 62
Model name:            Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
Stepping:              4
CPU MHz:               2500.046
BogoMIPS:              5000.09
Hypervisor vendor:     Xen
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              25600K
NUMA node0 CPU(s):     0

RAM = 2 GB

I am doing a test in j-meter with 500 concurrent threads and ramp up period of 10 sec. I get a throughput of 3/sec. How do i know this throughput is good or bad. Are there any benchmarks from which i can compare my results ie. throughput and deviation.

Upvotes: 1

Views: 323

Answers (1)

timbre timbre
timbre timbre

Reputation: 13960

There's no "good" or "bad" throughput per se. Depending on the goals of the application, and expectations of your stakeholders, 3/sec throughput can be perfect or terrible. So first question would be what are your performance goals?

Secondly, conclusion about throughput can only be reached when you have a graph, not a single point. A typical graph for throughput looks like this:

enter image description here

so without having points with lower and higher number of users, you don't really know if you are on "growing" or "plateau" phase. Also throughput graph may look like this:

enter image description here

so having only one point you also don't know if it is growing, on plateau or deteriorating.

Finally number of users is only one parameter that can influence throughput. Others may include: types of requests, size of data, duration of the test (e.g. long test may show throughput tendencies to increase or degrade invisible on shorter test), etc.

So my suggestion would be:

  • Check with your stakeholders what the goals of your application are. For example what do developers expect throughput to be.

  • Establish a solid benchmark in terms of operations. Something that represents the "majority of users". Make sure your test takes into account operations that may drastically change the throughput (or at least know which of them you excluded on purpose).

  • Establish the duration of the test, which will likely show a stable throughput (for some applications it can be 10 min, for others it might be 24 hours)

  • Without changing the test, run it multiple times with incrementing number of users (e.g. 100, 200, 300, ...) to obtain a graph. Continue to increase number of users until either application breaks or performance deteriorates to unacceptable rates.

That will give you the full picture and a good understanding if 3/sec throughput is the best your app can do, or it can do much better. And whether the best your app can do is good enough for your stakeholders.

BTW second picture was taken from this page, which is a really good read on the topic.

Upvotes: 1

Related Questions