我们想要启动一个大型多层应用程序。服务器端应用程序必须同时响应超过1000个用户。我们想用64位编译器和客户端用32位创建服务器应用程序。在这种情况下，我们不知道DataSnap可以毫无问题地响应所有客户端吗？ 在这种情况下，服务器计算机功能非常强大（多处理器和超过16GB的RAM），DataBase管理系统是FireBird 2.5。
答案 0 :(得分：12)
您需要一种方法来执行实际的负载测试。
对于Firebird数据库，您可以使用免费的Apache JMeter工具模拟并发用户。它可以运行SQL语句并记录它们的执行时间统计信息（平均值，最小值/最大值等）。因此，您可以创建一个包含20个不同SQL查询的线程组，然后运行20个线程，每个线程将按顺序执行这些查询。
JMeter允许定义SQL查询的时间限制，如果查询超出此限制，JMeter会将其视为错误。然后，您可以尝试查找总体错误率仍低于（例如）5％的最大客户端数。
但是您还需要知道预期的数据库负载有多高，并且您还需要具有实际大小的测试数据库，而不仅仅是几个记录。此外，某些数据库查询（如报告）可能会导致更高的负载 - 这些也应包含在模拟中，因为它们会影响整体性能。在JMeter中，您可以创建第二个线程组，与第一个线程组并行运行，用于具有不同设置的这些长时间运行的语句（模拟客户端较少）。
测试数据库将显示此区域是否存在瓶颈。例如，测试结果可能是数据库可以服务20个客户端，总平均事务速率为20 TPS（每秒事务数），这意味着一个客户端每秒执行一个事务。但是这个TPS值会随着用户数量的增加而减少。
相关问题：Firebird usage in big projects也有http://www.firebirdsql.org/en/case-studies-catalog/
的链接关于DataSnap客户端负载模拟：这可以通过脚本化客户端完成，该客户端通过连接运行预定义的一组语句/命令。 要同时运行大量负载测试客户端，您可以使用Amazon Elastic Compute Cloud（EC2）等服务来启动测试计算机映像的克隆，从而节省硬件成本。但是，当然我会从一台小型客户端机器开始，它只运行十到二十个脚本客户端。
答案 1 :(得分：10)
据我所知，DataSnap基于Indy。 Indy的连接处理模型不是很容易扩展 - 每个连接一个线程，这非常耗费资源。即使使用Indy的线程池也不是我认为的选项......例如，在Windows（32位）中，您可以创建的最大线程数限制（2000 IIRC）。无论如何 - 使用许多线程并不好并且达到了服务器的性能（供参考--Windows Internals书，Windows性能团队博客等）。
可扩展，强大且专业的应用程序服务器将使用IO完成端口（IOCP）进行数据处理。但我不知道DataSnap是否可以利用它。
<强>更新 在CodeRage7上，我问过类似的可扩展性问题。以下是答案：
问：最近在StackOverflow上有一个关于DataSnap可扩展性/性能的问题。那么DS可以在网络和应用程序级别处理2000或更多的用户请求吗？
A：可扩展性基于TCP / HTTP / HTTP的可扩展性和服务器操作系统中允许的连接数。也基于您使用的内存和硬件。 DataSnap没有特别限制。
我的评论：虽然这是事实，但Indy的连接处理模型，即每个连接一个线程，特别是在32位Windows（最多2000个线程）中引入了瓶颈。在Win64中，它应该不是那么多问题，但是再次 - 这种处理数据流导致性能下降。
问： DataSnap是否支持某种负载均衡？
A：不直接。您可以在DataSnap服务器的代码中执行此操作。
我的评论：我在Andreano Lanusse博客的implementing Failover/Load Balancing in DataSnap上发现了非常好的论文
问： DataSnap是否支持IO完成端口以实现更好的可扩展性？
我的问题没有答案。
希望这有帮助！
<强> UPDATE2：
我在DS Performance上发现了非常有趣的帖子：DataSnap analysis based on Speed & Stability tests
<强> UPDATE3：
答案 2 :(得分：3)
当制定系统规格时，您需要非常精确地了解多个用户。
例如：您创建一个网站，客户端需要15.000个唯一身份用户。 然后客户端通常会提出系统需要支持15.000个并发用户的要求，这非常幼稚。
您需要更详细的规范。
通常情况下更明智的是：在99％的请求中，99％的用户可以在5秒的平均时间内得到对他们请求的响应。
在正常使用情况下，您永远不会看到所有用户在同一秒内发送请求。如果在某个时刻它们都在同一分钟内到达（也非常不可能），那么并发用户将会少得多。
即使对于拥有成千上万用户的网站，其中大多数用户每天都会连接，网络服务器大多数时间都处于空闲状态，而且偶尔会跳到5％，或者在极端情况下达到20％。如果我们真的必须立即为所有这些用户服务，我们就会被搞砸，但这种情况从未发生过，为这样的负载准备服务器是不现实的。