Google App 引擎 - 了解实例是如何启动的以及需要什么内存（Java）

Question

我试图准确了解应用引擎如何为新请求启动新实例。 我已经使用应用程序引擎工作了一段时间，但我不知道哪里不知道文档（还没有完成我的“作业”）以及哪里存在错误/调度程序问题。

我刚刚尝试创建一个仅包含“Hello world”servlet 的新 Web 应用程序项目（Java - Eclipse）。 然后我将它部署到我的云控制台应用程序的测试版本上，以查看首次加载时需要多少内存。

有两个发现我不明白：

1. 在我调用测试 servlet 后，实例已经消耗了 120Mb。 为什么需要这么多内存？ 这是实例的java jvm的内存，还是容器的全部？
2. 每次我调用 servlet 时都会启动一个新实例。 我调用（随后，不是并行）它 10 次，我有 9 个实例（每个实例 1 个请求），一个处理了 2 个请求。 之后，大多数请求由现有实例处理，但其中一些请求再次产生新实例。 为什么？ （在每次测试（调用 servlet）之后，我在发出新请求之前等待接收响应和几秒钟）

我的 appengine-web.xml 文件是：

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
  <application>[...]</application>
  <version>test-memory</version>

  <!--
    Allows App Engine to send multiple requests to one instance in parallel:
  -->
  <threadsafe>true</threadsafe>

  <!-- Configure java.util.logging -->
  <system-properties>
    <property name="java.util.logging.config.file" value="WEB-INF/logging.properties"/>
  </system-properties>

    <sessions-enabled>true</sessions-enabled>

    <precompilation-enabled>true</precompilation-enabled>

    <instance-class>F1</instance-class>
      <automatic-scaling>
        <min-idle-instances>1</min-idle-instances>
        <max-idle-instances>2</max-idle-instances>
        <min-pending-latency>350ms</min-pending-latency>
        <max-pending-latency>automatic</max-pending-latency>

      </automatic-scaling>



</appengine-web-app>

服务端代码：

public class TestAppEngineMemServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws IOException {
        resp.setContentType("text/plain");
        resp.getWriter().println("Hello, world");
    }
}

我使用 Java 1.9.42 SDK 进行了测试，并将 Java 8 用于具有 Java 编译器合规性级别 7（如果重要）、具有 F1 或 F2 实例类的标准环境的本地开发。

请指教，谢谢。

Answer 1

产生新实例的机制实际上非常简单。 您有待处理的延迟，即请求在由可用实例处理之前在队列中的时间。

如果待定延迟超过阈值，您指定将启动一个新实例。

现在你应该感兴趣的是每次启动新实例时都会发生的预热请求，因此需要更长的时间。

让我们假设你的测试是这样的

t+0s: request #1 (causes warmup since there is no instance yet)
t+1s: request #2 (causes warmup since the first instance is not there yet)
t+2s: ... you get where this is going ...
t+8s: the first instance is now ready to serve and requests are being processed
t+9s: the second instance is now ready to serve
t+xs: request #x (does not cause warmup requests because there are enough instances)
t+xs: instances slowly spin down because there isn't enough traffic to justify its existence 

您在这里看到的是，您的请求不必同时引起看似愚蠢的行为。

至于内存（这真的应该是一个单独的问题）：你看到的是容器/虚拟机使用的内存。 这大约是您的 Java VM 的内存 + 可能是容纳它的 docker 映像环境的一些样板。 Java 为运行时分配内存，因此与 C/C++ 相比，它总是相对较高（您可以使用 -Xms/-Xmx 参数在本地指定它）

所以内存不是必需的，而是分配给 JVM 使用的。 内存量可能会随着时间的推移而增加，但是当 JVM 中的内存被释放时，它不一定会立即返回给系统。