扩展系统使用的注意事项

时间:2011-09-01 16:00:15

标签: performance architecture scaling

我有一个系统,它使用远程数据库和前端的Web应用程序。

系统现在处于可以扩大使用范围的阶段(即,由一个人测试,被100人使用)......

显然,对于大群人来说,测试等会有一个阶段,但我想知道是否有经验的人在以这种方式扩展系统时能给我提供考虑的要点(即常见问题和解决方案)。 ..

一个例子可能是服务器空间......确保总是足以适应系统使用的增长......

听到相关问题会很有趣,因为这是我的第一个大项目......

2 个答案:

答案 0 :(得分:1)

最终答案对每个应用程序都是独一无二的。尝试找到一些具体的证据,证明“正常”使用会带来什么,如果可能的话,还有什么时候和最大用量。确定您的应用可接受的性能,并使用负载测试工具,如JMeter(免费)或WAPT(非免费)来模拟用户负载并查看您的应用如何保持。如果您没有获得可接受的性能数字,请将VisualVM(免费,也与JDK捆绑在一起)或YourKit(非免费)等分析器放入混合中以识别瓶颈。修复最严重的瓶颈,冲洗并重复。

答案 1 :(得分:1)

我看到了三件重要的事情:

  1. 意外的互动。
  2. 严重调整参数和无理性退化
  3. 意外资源消耗
  4. 首先,你必须有明确的目标。 @Ryan已经提到了这一点。可接受的性能是什么样的 - 您的目标不是“尽可能快”或者您永远不会停止调整 - 您必须非常清楚:指定用户群的指定工作负载模式响应时间是......

    当您扩大工作量时,您可能会遇到我之前提到的问题。

    意外交互:例如,某些用户操作会导致冗长的数据库活动,并且在某些锁定期间,其他用户现在会遇到无法接受的性能。或者,几个用户都试图同时购买相同的产品,发生了不可接受的乐观锁定故障。或者系统死锁。

    这些问题通常在测试结果出现之前不会出现。要检测此类问题,您需要仔细设计测试数据,并测试脚本以涵盖正常和“异常”峰值。

    调整参数:您的基础架构可能具有连接池和线程池。可能需要调整这些池的默认大小。这里有两个注意事项,对于你的目标工作负载有什么作用?您增加了连接池大小,所以现在数据库服务器有更多的打开连接,所以现在需要增加一些数据库参数或可用内存......以及在资源耗尽时异常情况下会发生什么。假设系统超时等待连接 - 用户是否收到友好的错误消息并且系统管理员收到通知或发生了非常不愉快的事情?

    意外资源消耗:工作负载扩展时资源消耗会发生什么变化?日志现在要大得多,因此磁盘空间不足吗?你需要增加堆大小吗?随着时间的推移,长期趋势是什么?记忆力增长?也许内存泄漏?通常会有令人不快的惊喜。