小编Zuf*_*fra的帖子

我已经检查了所有类似的问题，每个答案都说我需要指定一个已经执行的driverClassName。这是我的application.yml：

spring:
  application:
    name: cibus-backend
  datasource:
    driverClassName: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/Cibus?useSSL=true
    username: root
    password: 1234567890
  jpa:
    show-sql: true
    hibernate:
      ddl-auto: update
      properties:
      hibernate:
        format_sql: true
        type: trace
    database-platform: org.hibernate.dialect.MySQL5InnoDBDialect
    database: mysql
logging:
  level:
    org:
      hibernate:
        type: trace

我想念什么吗？奇怪的是，我的一个拥有相同代码的同学可以很好地启动该应用程序。这就是为什么我认为它与路径有关。也许spring不能访问yml文件。我将它包含在src.main.resources中，这是Spring查找它的默认位置。这是堆栈跟踪：

Error starting ApplicationContext. To display the conditions report re-run         
your application with 'debug' enabled.
2018-10-21 10:13:15.657 ERROR 10356 --- [JavaFX-Launcher]             
o.s.b.d.LoggingFailureAnalysisReporter   : 

***************************
APPLICATION FAILED TO START
***************************

Description:

Failed to configure a DataSource: 'url' attribute is not specified and no embedded datasource …

我最近使用Zappa将 Django 后端应用程序部署到 AWS Lambda 。

在一段时间内未调用 lambda 函数后，发出的第一个请求需要 10 到 15秒的时间才能处理。起初我以为这是因为冷启动，但这次即使是冷启动也是不可接受的。然后，通读 Zappa 的文档，我发现它默认启用keep_warm每 4 分钟向 lambda 函数发送一个虚拟请求以保持温暖的功能；因此，对 lambda 的第一个请求的响应的过度延迟并不是由于冷启动造成的。

然后，我开始使用 AWS X-Ray 和 Cloudwatch Insights 等工具来尝试找到延迟的解释。这是我发现的：

需要很长时间才能处理的调用如下：

用红色划掉的是应用程序使用的环境变量的名称。它们都是直接在 AWS 控制台中定义并分配值的。我不明白的是，首先，为什么需要这么长时间，其次，为什么它说环境变量被转换为None. 该应用程序运行完美（除了第一个请求中的大量延迟之外），因此环境变量在某处正确设置。

此请求每隔两个小时虔诚地发出一次，并且在一段时间内有人第一次调用 lambda 函数，如下图所示：

x 轴上的点对应于 Zappa 保持服务器温暖的虚拟请求。升高的点对应于上图中所示的调用。最后，峰值对应于用户调用。处理时间是处理长调用（第一张图中所示）所需时间和处理客户端向服务器发出的最长 http 请求所需时间的总和。该请求如下：

这是一个常规的登录请求，应该更快地得到解决。其他可能比这个要求更高的请求在不到 100 毫秒的时间内得到了解决。

所以，总结一下：

1. 有一个 lambda 调用需要 10 秒以上才能解析。这对应于显示的第一张图像。每 2 小时执行一次，当用户在服务器空闲一段时间后向服务器发出请求时执行一次。
2. 有些请求需要 2 秒以上才能解决，我不知道为什么会这样。
3. 除了这些先前的函数调用之外，所有其他请求都会在合理的时间范围内得到解决。

非常感谢任何关于为什么这些调用可能花费这么多时间的想法，因为我花了相当长的时间试图自己弄清楚，但我已经没有想法了。先感谢您！

编辑1（28/07/21）：为了进一步支持我的怀疑，即这种延迟不是由于冷启动造成的，这里是Cloudwatch/应用程序监控/跟踪中函数的“分段时间线”：

如果是冷启动，延迟应该出现在“初始化”段中，而不是“调用”段中。

编辑 2 (30/07/21)：我忘了提及，我之前使用 Elastic Beanstalk 部署了应用程序，并且没有遇到此问题，因此我的代码的性能可能不是这里的问题。

编辑 3 (30/07/21)：我在 2016 年的 AWS …

我将 Django 应用程序部署到 Elastic Beanstalk (EB) Amazon Linux 2 Python 3.7 平台，一切似乎都工作正常。然而，环境卫生却很严峻，我不明白为什么。

EB 给我的唯一信息如下：

总体状态：降级 - 所有实例上的服务均受损。

（只有一个实例在运行）

实例状态：严重 - 以下服务未运行：释放。

我没有找到有关“发布”服务是什么的信息。

从完整的日志中，我看到的唯一错误如下：

守护进程日志：

F, [2020-11-07T04:03:03.891398 #5022] FATAL -- : /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.6.0/gems/puma-4.3.5/lib/puma/launcher.rb:432:in `block in setup_signals': SIGTERM (SignalException)
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.6.0/gems/puma-4.3.5/lib/puma/single.rb:117:in `join'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.6.0/gems/puma-4.3.5/lib/puma/single.rb:117:in `run'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.6.0/gems/puma-4.3.5/lib/puma/launcher.rb:172:in `run'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.6.0/gems/puma-4.3.5/lib/puma/cli.rb:80:in `run'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.6.0/gems/healthd-1.0.6/bin/healthd:112:in `block in <top (required)>'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.6.0/gems/healthd-1.0.6/bin/healthd:19:in `chdir'
    from /opt/elasticbeanstalk/lib/ruby/lib/ruby/gems/2.6.0/gems/healthd-1.0.6/bin/healthd:19:in `<top (required)>'
    from /opt/elasticbeanstalk/lib/ruby/bin/healthd:23:in `load'
    from /opt/elasticbeanstalk/lib/ruby/bin/healthd:23:in `<main>'

从我在这里读到的内容来看，抛出这个 SignalException 是为了关闭进程，所以我认为这是正常的。

其他任何日志中都没有其他错误。关闭增强的运行状况检查将是此处所述的简单“解决方案” ，但我想保持它们打开。

很感谢任何形式的帮助。