除了硬件，还有什么影响并发用户数方面的性能？答案

【问题标题】：Apart from hardware, what affects the performance in terms of number of concurrent users?除了硬件，还有什么影响并发用户数方面的性能？
【发布时间】：2013-01-16 14:21:16
【问题描述】：

我正在开发一个 API，并且希望（当然）根据并发用户数来优化性能。

我已经使用 Blitz 运行了一些测试（我的应用在 Appfog、PHP、512MB、1 个实例上），根据这些测试我的 API 可以在响应时间变得太高（>1000 毫秒）之前处理 11 个并发用户。

对我来说，这个数字低得惊人。我可以添加更多 RAM 和实例来改善结果，但我怀疑我的代码可能更智能。

我做了一些测试，总是使用相同的硬件配置。结果是响应时间超过 1000 毫秒之前的并发用户数。

使用我的实际 API（带有 db-queries）--> 11 个用户
使用仅输出文本的脚本（最少处理）--> 40 个用户
使用带有 sleep(2) 函数的脚本来模拟较长的响应时间 --> 52 个用户（超过 (2000 + 1000 ms) 之前）
使用内存密集型脚本（使用 for 循环构建数据）：95 个用户

我真的看不出结果中有任何相关性（每个测试都运行了很多次，结果相似）。脚本的处理越多 - 并发用户越多？

是什么影响了并发用户的数量（除了硬件配置）？

【问题讨论】：

这看起来像 db 可能是你的瓶颈。你测量过你的 SQL 语句的执行时间吗？
此外，一般而言，Web 应用程序可以处理的并发用户数受很多因素的影响。你能缩小你的问题范围，更具体地解决你的具体问题吗？
我已经测量了 DB-queries 并开始使用 memcache。它大大提高了响应时间，但并没有提高并发用户的数量。这就是为什么我做了一些测试，这些结果对我来说没有任何意义。他们告诉我，如果我降低执行时间和内存使用量并不一定会导致更多的并发用户。所以基本上我想了解我应该关注哪些指标来提高并发用户的性能。
使用 sleep() 来模拟更长的执行时间可能不像你想象的那样工作。这将暂停当前线程的执行，但不会增加 CPU 负载。这意味着吞吐量（这是您作为“并发用户”测量的）在 CPU 负载方面不会发生变化。您能否进一步解释一下您如何解释上述各个结果以得出“[...] 较低的执行时间和内存使用量并不一定会导致更多的并发用户。”？
好的，这解释了我的部分结果！然后我只对测试2和测试4感到困惑。测试2只是一个回显语句，测试4是一个for循环（x100000），它进行一些计算然后回显一条消息。也许这样的 for 循环不是那么 CPU 密集型（？），但我很困惑测试 4 的性能要好两倍！我希望它与 test2 差不多或更差。

标签： performance appfog blitz++

【解决方案1】：

一般你应该考虑两个方面：

数据库或外部 API 等瓶颈。你和最慢的组件一样慢
寻找将并发代码转换为顺序代码的锁。见：Amdahl's law

第二点与第一点有关。数据库或您在代码中使用的任何内容可能是内部同步的，或者可能无法很好地处理并发。

【讨论】：

我正在使用 MongoLab 和 MemCachier。它们都是 Appfog 的插件，所以我可以远程访问它们（所有服务都在 AWS-EU-West 运行），这会是瓶颈吗？您会将它们定义为“外部”吗？如果它们是瓶颈，那会影响 CPU 使用率吗？我的意思是，如果数据库（在 MongoLab 上，即另一台服务器上）响应缓慢，那是否只会影响总响应时间而不影响我的应用程序的负载（=并发用户性能）？
@luttkens：你说得对，响应时间 != 吞吐量。但是例如如果数据库负载过重，随着连接数量的增加，响应速度会变慢。唯一 100% 的方法是添加一些分析/日志记录，并找出架构的哪些部分花费了大部分时间。
最终发现是数据库成为了瓶颈！由于网络服务器（PHP）上的线程与数据库查询一样长（并占用内存），因此数据库响应缓慢，查询后添加upp。