我们在IBM Mobilefirst适配器中遇到性能问题。我们使用的是IBM Mobilefirst版本7.1.0.0-IF201807271401。当用户强度增加到1000时，适配器将花费超过50秒来命中ESB服务，其中当用户强度小于20时，适配器将在一秒内命中ESB。
请查看以下详细信息以获取更多信息
应用架构：
App <---> Adapter <---> ESB <--->数据库
Case 1: Users strength is less then 20 users
Request made in App: 10:15:00 AM
Request reached in Adapter: 10:15:00 AM
Request reached in ESB: 10:15:00 AM
Case 2: Users strength is increased towards 1000
Request made in App: 10:15:00 AM
Request reached in Adapter: 10:15:00 AM
Request reached in ESB: 10:15:55 AM
我们为这个项目做了最好的硬件设置。 RAM或CUP没有问题。我们还观察到当用户强度达到1000时，CPU利用率低于15％。
请让我们知道为什么适配器在用户强度增加时获得更多时间并且解决方案也相同。
您似乎遇到了经典的资源争用案例。您还没有提到您使用的是哪种适配器以及您的应用程序服务器 - 具体是节点数。
假设Javascript HTTP适配器（您正在连接到ESB），请注意它的默认并发性为50.这意味着可以从适配器向后端打开最多50个并发连接。假设您有两个部署运行时的应用程序服务器节点，那么这将成为与ESB建立的100个可能的并发连接。这适用于所有JavaScript HTTP适配器。
当1000个用户登录并且所有用户都调用相同的适配器时，从该适配器到ESB只能进行100个并发连接。这意味着其余的必须等到现有连接完成。您没有提到ESB可以支持的最大并发数。还有，你的后端。如果ESB不能支持100个并发用户，那么将在ESB上限制连接。后端也会发生同样的情况。这意味着从移动设备到达的实际请求正在等待。现在，并非所有用户都将调用相同的适配器。请求可能分布在所有适配器上，如果所有适配器都通过相同的ESB，则ESB将一直加载，并且可能没有足够的可用空闲连接。
您自己的观察结果表明，该系统在20个并发用户中运行良好，但没有扩展到支持1000.单靠最好的硬件部署是不够的。您需要配置应用程序服务器，适配器，后端和ESB以实现高并发性。
验证ESB可以支持的并发连接数。计算后端响应的时间。找到后端和负载后请求的总周转时间。然后适当调整大小。如果为适配器中的“maxConcurrentConnectionsPerNode”属性设置了一个非常高的数字，则降低它以匹配ESB的功能。此外，分析并设置适当的连接并读取适配器的超时值，以便等待太长时间的连接将超时并且可以释放Webcontainer线程。