Playframework 在“application.conf”文件中从DEV模式更改为PROD模式时会发生什么？

我正在使用play framework 1.2.5，在过去的两天里，我在负载测试方面遇到了一个非常大的问题，即对于服务器的每个API调用，平均需要1200-1400ms，但今天我只更改了application.conf文件中的以下一行，这将平均时间大幅减少到20-50ms，如下所示

  application.mode=prod
  %prod.application.mode=prod

一开始就像

  application.mode=dev 
  %prod.application.mode=prod

因此，从这一点我可以理解，从开发到生产的转变带来了一些东西，我在互联网上发现的是，在开发模式下，默认情况下play.pool=1，而在生产模式下play.pool=no of processors+1，我的ubuntu机器是4个处理器，所以它使用5个线程。现在问题来了，如果我发现的是真的，那么当我在application.conf中手动更改play.pool=5时，也不会给出更快的结果。如果我设置play.pool=1并在生产模式下运行，也不会减慢我的应用程序loadtest结果，所以我需要知道当我从dev更改为prod模式时会发生什么，除了这个play.pool，它使我的应用程序更快。因为我在UAT中面临的问题是，在prod模式下更改也没有好的结果，它只在我的本地主机上工作。请尽快为我找到解决方案，谢谢

更新：

是的，我确实知道所有这些事情，比如在开发模式下，应用程序会重新加载和编译，但是，我想，可能不是每个请求都只在初始程序加载时进行，但我的问题是，这种prod模式在我的本地主机和本地服务器上运行良好，当我进行UAT时，平均在800毫秒左右的负载测试中，我会得到一个糟糕的结果。即使在prod中，应用程序也很慢，即使我在本地执行loadtest jmeter安装在服务器机器中，并且我正在使用远程桌面连接进行负载测试。因此，除了编译和重新加载之外，我需要知道当我从DEV模式更改为PROD模式时，application.conf文件中执行的所有更改是什么，比如play.pool从1个线程更改为no of processors+1个线程。

---

仅供参考：我的本地主机系统是4个处理器的机器，本地服务器机器是4个处理器，但UAT机器是2个处理器，如果这是问题，我甚至尝试将池线程更改为10play.pool=10，但在UAT上没有好的结果

除单线程外，在开发模式下，应用程序启动会延迟到发送第一个请求。在prod模式下，应用程序将立即启动。这显然会影响第一个请求的加载时间

我猜在开发模式下的“糟糕”性能主要是由运行时重新加载和编译类的特性造成的。在每个请求中，都会检查类的更改，并且可以重新加载。我认为这项功能非常值得增加加载时间，我不知道是否有可能停用

---

您可能不应该在开发模式下运行任何性能/验收测试。您不应该试图提高开发模式的性能，而应该只使用prod模式

你应该在开始行动之前做更多的分析。 首先，你要试着了解额外的时间花在哪里

呈现模板？ 挂起等待DB连接？ 有螺纹锁吗？ 数据库是否已使用索引进行了优化？ 您测量过处理器和内存使用情况吗？ 您是否正在进行任何昂贵的IO操作？ 这台机器上是否正在运行其他进程？

---

如何在生产服务器上启动play

我希望你读过：

---

您的问题实际上是关于性能问题。可能有许多因素会导致您的本地环境和生产环境的性能差异。除了播放，DB是否在同一个盒子上运行

是的，我知道在开发模式下重新加载和编译的所有内容，但我的问题是，在本地主机和本地服务器上，从开发模式更改为生产模式的想法很好，但在美国的测试站点上，这种想法并不好。请查看问题中的我的更新是的，数据库正在同一台机器上运行。