linux/apache在1000个并发请求上的性能基准

我有一台linux服务器，配置如下：

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

我在j-meter中做一个测试，有500个并发线程，上升周期为10秒。我的吞吐量是3/秒。我如何知道这个吞吐量是好是坏。是否有任何基准可以用来比较我的结果，即吞吐量和偏差。

吞吐量本身没有“好”或“坏”之分。根据应用程序的目标和利益相关者的期望，3/秒的吞吐量可能是完美的，也可能是糟糕的。所以第一个问题是你的绩效目标是什么

其次，只有当你有一个图表，而不是一个点时，才能得出关于吞吐量的结论。吞吐量的典型图表如下所示：

因此，如果没有用户数量越来越少的点数，你就不知道自己是处于“成长”阶段还是“稳定”阶段。此外，吞吐量图可能如下所示：

所以只有一个点你也不知道它是在生长，在高原上还是在恶化

最后，用户数只是影响吞吐量的一个参数。其他可能包括：请求类型、数据大小、测试持续时间（例如，长测试可能会显示吞吐量增加或降低的趋势，在较短的测试中不可见），等等

因此，我的建议是：

• 与利益相关者核实应用程序的目标是什么。例如，开发人员期望吞吐量是多少

• 在运营方面建立坚实的基准。代表“大多数用户”的东西。确保您的测试考虑到可能会显著改变吞吐量的操作（或者至少知道您故意排除了哪些操作）

• 确定测试的持续时间，这可能会显示稳定的吞吐量（对于某些应用程序可能是10分钟，对于其他应用程序可能是24小时）

• 在不更改测试的情况下，以递增的用户数（例如，100、200、300等）多次运行测试，以获得图形。继续增加用户数量，直到应用程序中断或性能恶化到不可接受的速率

如果你的应用程序的吞吐量是3/秒，或者它可以做得更好，那么这将为你提供一个完整的画面和一个很好的理解。你的应用程序所能做到的最好，对你的利益相关者来说是否足够好

顺便说一句，第二张照片是从，这是一个非常好的阅读主题