我在tomcat上有一个应用程序（无水平缩放），我发送20个请求。每个请求执行6-7分钟的复杂计算。
我在具有多个内核（50多个）的独立服务器上运行相同的服务器，每个请求都在单独的逻辑处理器上的线程中执行-执行时间为3-4分钟。
在Jelastic平台上，它最多可扩展40-42个小云（即使最大为92）。有没有一种“影响”缩放的方法，告诉Jelastic应该使用更多的cloudlets。 （我想42个cloudlets上的处理器少于20个，并且线程之间共享时间。）
如果我再发送两次（40个请求），它会使用大约65个cloudlets（在这种情况下，最大值设置为160）。
我能在任何地方找到什么规则，Jelastic如何决定如何扩展以及如何使用更多的cloudlets？
Jelastic节点的整体计算能力取决于小云扩展限制。如果您有大量计算工作量，则应牢记预算限制，将此值设置得尽可能高。 （您还可以配置负载警报，以通知您持续过量使用情况）
cloudlet的使用量（按计费方式）是按每小时的平均CPU使用量计算的，因此，如果您的峰值为几分钟（如您的示例所示），则希望允许它使用尽可能多的CPU。可以。
您看到的使用情况是您的工作负载如何分布在各个核心上的函数，由于您设置的cloudlet限制，每个核心的实际计算能力可能受到人为限制。为了获得最佳性能，您必须允许很高的cloudlet限制，因为这将使您能够完全访问每个内核，而不是（有效地）限制每个内核的时钟速度。
您设置为保留的cloudlet的内容无关紧要（这纯粹是一种计费结构：没有技术影响），也没有从服务器中添加或删除cloudlet-再次，这纯粹是一种计费结构，而不是技术性的结构。这意味着没有办法指示Jelastic使用更多的cloudlet：发生这种情况完全是由于代码的执行方式（很可能是由于您设置的总体cloudlet限制与Java的计算能力相比，它在内核中的分布方式）基础硬件）。
在不同的Jelastic供应商中，您的性能也可能会有所不同，具体取决于他们的硬件选择。例如，某些将使用较低时钟速度的大量内核，而另一些可能将时钟速度优先于内核数目。在这种情况下，您的应用程序性能将取决于跨内核并行化（多线程）的效率。如果您最繁重的工作无法并行化，则在更高的时钟速度下将能最好地工作。鉴于您通过更多请求增加了Cloudlet的使用量，这听起来至少对您的情况负有一定责任。
您可能还会考虑，如果您使用专用硬件具有更好的性能，则可以将Jelastic作为私有或混合云选项使用。他们还可能在不同地区提供不同的硬件选项，以满足不同类型的工作负载。与您的Jelastic供应商联系，看看他们可以为您提供什么。