Jetty 中的传输速度较慢，在特定缓冲区大小下采用分块传输编码

我正在调查 Jetty 6.1.26 的性能问题。 Jetty 似乎使用Transfer-Encoding: chunked，并且根据所使用的缓冲区大小，本地传输时可能会非常慢。

我创建了一个小型 Jetty 测试应用程序，其中包含一个演示该问题的 servlet。

import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.OutputStream;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.mortbay.jetty.Server;
import org.mortbay.jetty.nio.SelectChannelConnector;
import org.mortbay.jetty.servlet.Context;

public class TestServlet extends HttpServlet {

    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        final int bufferSize = 65536;
        resp.setBufferSize(bufferSize);
        OutputStream outStream = resp.getOutputStream();

        FileInputStream stream = null;
        try {
            stream = new FileInputStream(new File("test.data"));
            int bytesRead;
            byte[] buffer = new byte[bufferSize];
            while( (bytesRead = stream.read(buffer, 0, bufferSize)) > 0 ) {
                outStream.write(buffer, 0, bytesRead);
                outStream.flush();
            }
        } finally   {
            if( stream != null )
                stream.close();
            outStream.close();
        }
    }

    public static void main(String[] args) throws Exception {
        Server server = new Server();
        SelectChannelConnector ret = new SelectChannelConnector();
        ret.setLowResourceMaxIdleTime(10000);
        ret.setAcceptQueueSize(128);
        ret.setResolveNames(false);
        ret.setUseDirectBuffers(false);
        ret.setHost("0.0.0.0");
        ret.setPort(8080);
        server.addConnector(ret);
        Context context = new Context();
        context.setDisplayName("WebAppsContext");
        context.setContextPath("/");
        server.addHandler(context);
        context.addServlet(TestServlet.class, "/test");
        server.start();
    }

}

在我的实验中，我使用 servlet 返回给客户端的 128MB 测试文件，客户端使用 localhost 进行连接。使用用 Java 编写的简单测试客户端下载此数据（使用URLConnection）需要 3.8 秒，这非常慢（是的，它是 33MB/s，这听起来并不慢，除了这纯粹是本地的并且输入文件被缓存；它应该快得多）。

现在事情变得奇怪了。如果我使用 wget 下载数据，它是一个 HTTP/1.0 客户端，因此不支持分块传输编码，只需要 0.1 秒。这是一个更好的数字。

现在当我改变时bufferSize到4096，Java客户端需要0.3秒。

如果我删除对resp.setBufferSize完全（似乎使用 24KB 块大小），Java 客户端现在需要 7.1 秒，并且 wget 突然同样慢！

请注意，我绝不是 Jetty 方面的专家。我在使用reduce任务洗牌诊断Hadoop 0.20.203.0中的性能问题时偶然发现了这个问题，它使用Jetty以类似于缩减示例代码的方式传输文件，缓冲区大小为64KB。

该问题在我们的 Linux (Debian) 服务器和我的 Windows 机器上以及 Java 1.6 和 1.7 上都会重现，因此它似乎完全依赖于 Jetty。

有谁知道可能导致此问题的原因是什么，以及我是否可以对此做些什么？

我相信通过查看 Jetty 源代码，我自己已经找到了答案。它实际上是响应缓冲区大小、传递给的缓冲区大小的复杂相互作用outStream.write，以及是否outStream.flush被称为（在某些情况下）。问题在于 Jetty 使用其内部响应缓冲区的方式，以及如何将写入输出的数据复制到该缓冲区，以及何时以及如何刷新该缓冲区。

如果使用的缓冲区大小outStream.write等于响应缓冲区（我认为倍数也可以），或者更少并且outStream.flush使用的话，性能还是不错的。每个write然后调用直接刷新到输出，这很好。但是，当写入缓冲区较大且不是响应缓冲区的倍数时，这似乎会导致处理刷新的方式出现一些奇怪的情况，从而导致额外的刷新，从而导致性能不佳。

在分块传输编码的情况下，电缆中存在额外的扭结。对于除第一个块之外的所有块，Jetty 保留 12 个字节的响应缓冲区来包含块大小。这意味着，在我最初使用 64KB 写入和响应缓冲区的示例中，响应缓冲区中容纳的实际数据量仅为 65524 字节，因此，部分写入缓冲区再次溢出到多次刷新中。查看此场景捕获的网络跟踪，我发现第一个块是 64KB，但所有后续块都是 65524 字节。在这种情况下，outStream.flush没有什么区别。

当使用 4KB 缓冲区时，我仅在以下情况下才看到快速速度：outStream.flush被称为。事实证明resp.setBufferSize只会增加缓冲区大小，并且由于默认大小是 24KB，resp.setBufferSize(4096)是一个空操作。然而，我现在正在写入 4KB 数据，即使保留了 12 个字节，这些数据也适合 24KB 缓冲区，然后由outStream.flush称呼。然而，当调用flush被删除，它将让缓冲区填满，再次有 12 个字节溢出到下一个块中，因为 24 是 4 的倍数。

综上所述

看来要获得 Jetty 的良好性能，您必须：

• 打电话时setContentLength（无分块传输编码）并使用缓冲区write它的大小与响应缓冲区的大小相同。
• 当使用分块传输编码时，使用比响应缓冲区大小至少小 12 个字节的写入缓冲区，并调用flush每次写完后。

请注意，“慢”场景的性能仍然如此，您可能只会在本地主机或非常快（1Gbps 或更高）的网络连接上看到差异。

我想我应该为此针对 Hadoop 和/或 Jetty 提交问题报告。