3

我在扩展系统上的并发用户数量时遇到问题。从我的测试来看，扩展并发用户的数量似乎直接增加了请求的持续时间，呈线性关系。

我正在运行一个部署在具有 16Gb RAM 的（虚拟）Ubuntu 四核机器上的 Java Web 应用程序。我正在使用 Apache Tomcat 7 和 MySQl 5.5 数据库。Tomcat 和 MySQL 使用默认设置——我没有以任何方式配置它们。

我正在使用 Apache Benchmark 运行许多测试，最终创建一个 SQL 查询以返回一行数据，其中响应大小非常小。

我使用 Spring 的 JDBCTemplate 和 Apache Commons BasicDataSource。spring bean 的配置如下所示。

<!-- READ ONLY CONNECTION TO DATABASE -->
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
  <property name="driverClassName">
    <value>com.mysql.jdbc.Driver</value>
  </property>
  <property name="username">
    <value>${database.username}</value>
  </property>
  <property name="password">
    <value>${database.password}</value>
  </property>
  <property name="url">
    <value>${database.url}/${database.schema}</value>
  </property>
  <property name="timeBetweenEvictionRunsMillis" value="7200000" />
  <property name="minEvictableIdleTimeMillis" value="3600000" />
  <property name="maxActive" value="100" />
  <property name="maxIdle" value="5" />
  <property name="defaultAutoCommit" value="false" />
  <property name="defaultReadOnly" value="true" />
</bean>

<bean id="myDao" class="...">
   <property name="jdbcTemplate" ref="jdbcTemplate"></property>
   <property name="dataSource" ref="dataSource"></property>
</bean>

<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
   <property name="dataSource" ref="dataSource" />
</bean>

我的创建几个查询的 Java 方法用 @Transactional 注释。

这些是我的测试结果：

  • 1 个请求需要 0.2 秒。
  • 10 个请求（同时执行）需要 0.9 秒。

因此，您可以看到我的应用程序没有缩放。我不确定问题的原因可能是什么。谁能看到我做错了什么或建议我可以进一步调查的方法？

提前致谢，

菲尔

更新

更多指标：

  1 个请求，并发 1 = 0.22s
 10 个请求，并发 10 = 0.6 秒（平均），0.5（分钟）
100 个请求，并发 100 = 7（平均），3.7（分钟）
300 个请求，并发 300 = 12 秒（平均），4.3（分钟）
300 个请求，并发 300 = 18 秒（平均），6.4（分钟）

响应大小为 1kb。

尝试相同的请求并更改并发：

300 个请求，并发 8 = 总时间：14.9s
300 个请求，并发 20 = 总时间：15.3s
300 个请求，并发 300 = 总时间：24 秒

因此，将并发减少到 8 比并发 300 快 10 秒。从 8 增加会减慢事务。8 似乎是最优化的并发。

4

1 回答 1

3

尝试使应用程序并发时需要考虑一些事项。

首先，仅仅因为您的服务器有四个内核，并不意味着它们都对您的 JVM 可用，您需要询问运行时以查看有多少可用，并且在 JVM 的生命周期内这在技术上也是可能的，虽然很少见。

接下来，您需要考虑环境的物理拓扑。数据库是否与应用程序在同一台服务器上运行？如果是这样，您在处理和 IO 方面对资源有额外的争用，而不仅仅是您的应用程序正在做什么。

了解了这些要点后，您需要考虑应用程序的 IO 与处理配置文件。例如，查找素数并将它们输出到系统日志的应用程序实际上是 100% 处理与 0% IO。在这种类型的应用程序中，在应用程序中拥有比可用内核更多的线程是没有意义的，因为内核将不断地忙于它们正在做的事情，而任务切换的开销实际上会减慢你的应用程序。

与数据库密切相关的应用程序通常具有相对较高的 IO 到处理配置文件，尽管如果您只是读取并且这些读取相对较小，并且查询的数据在逻辑上布局良好的数据库，该配置文件的 IO 限制会减少. DB 的大小也会影响 IO，这取决于整个 DB 集是否可以保存在内存中或是否正在发生磁盘分页。

如果您不熟悉并发，我强烈建议您阅读 Brian Goetz 的 Java Concurrency in Practice。话虽如此，您正在采取一种明智的方法，即按原样分析您的应用程序。

于 2012-11-27T11:27:58.620 回答