一个明显的jetty-8大文件传输性能大幅降低问题分析

public class HttpOutput extends ServletOutputStream 
{
    /* ------------------------------------------------------------ */
    private void write(Buffer buffer) throws IOException
    {
        if (_closed)
            throw new IOException("Closed");
        if (!_generator.isOpen())
            throw new EofException();
        
        // Block until we can add _content.
        while (_generator.isBufferFull())
        {
            _generator.blockForOutput(getMaxIdleTime());
            if (_closed)
                throw new IOException("Closed");
            if (!_generator.isOpen())
                throw new EofException();
        }

        // Add the _content
        _generator.addContent(buffer, Generator.MORE);

        // Have to flush and complete headers?
        
        if (_generator.isAllContentWritten())
        {
            flush();
            close();
        } 
        else if (_generator.isBufferFull())
            _connection.commitResponse(Generator.MORE);

        // Block until our buffer is free
        while (buffer.length() > 0 && _generator.isOpen())
        {
            _generator.blockForOutput(getMaxIdleTime());
        }
    }
}

具体的耗时消耗在：_generator.blockForOutput(getMaxIdleTime());

从函数名字都可以看出来，当网络繁忙时，会走到这个流程，在blockForOutPut中，首先会注册一个socket可写的事件，当该socket上面可以写数据时，通知当前业务线程，随后业务线程投入休眠。等待事件分发线程检查可读事件，并唤醒自己。这样在这个交互中不可避免的会损失部分数据传输性能，每一包数据虽然只会损失一点点性能，但是传输一个很大的文件时，就会发现这个损失的巨大，在10GE的网卡上面，数据传输的性能降低到了原来的1/10，这个影响太明显了。

 

那么问题到底出在哪里呢？

看下面的代码：

public class HttpGenerator extends AbstractGenerator
{
    public void addContent(Buffer content, boolean last) throws IOException
    {
        if (_noContent)
            throw new IllegalStateException("NO CONTENT");

        if (_last || _state==STATE_END)
        {
            LOG.warn("Ignoring extra content {}",content);
            content.clear();
            return;
        }
        _last = last;

        // Handle any unfinished business?
        if (_content!=null && _content.length()>0 || _bufferChunked)
        {
            if (_endp.isOutputShutdown())
                throw new EofException();
            flushBuffer();
            if (_content != null && _content.length()>0)
            {
                if (_bufferChunked)
                {
                    Buffer nc=_buffers.getBuffer(_content.length()+CHUNK_SPACE+content.length());
                    nc.put(_content);
                    nc.put(HttpTokens.CRLF);
                    BufferUtil.putHexInt(nc, content.length());
                    nc.put(HttpTokens.CRLF);
                    nc.put(content);
                    content=nc;
                }
                else
                {
                    Buffer nc=_buffers.getBuffer(_content.length()+content.length());
                    nc.put(_content);
                    nc.put(content);
                    content=nc;
                }
            }
        }

        _content = content;
        _contentWritten += content.length();

        // Handle the _content
        if (_head)
        {
            content.clear();
            _content=null;
        }
        else if (_endp != null && (_buffer==null || _buffer.length()==0) && _content.length() > 0 && (_last || isCommitted() && _content.length()>1024))
        {
            _bypass = true;
        }
        else if (!_bufferChunked)
        {
            // Yes - so we better check we have a buffer
            if (_buffer == null)
                _buffer = _buffers.getBuffer();

            // Copy _content to buffer;
            int len=_buffer.put(_content);
            _content.skip(len);
            if (_content.length() == 0)
                _content = null;
        }
    }
}

 

问题出在下面这段代码上面：

// Handle the _content
if (_head)
{
    content.clear();
    _content=null;
}
else if (_endp != null && (_buffer==null || _buffer.length()==0) && _content.length() > 0 && (_last || isCommitted() && _content.length()>1024))
{
    _bypass = true;
}
else if (!_bufferChunked)
{
    // Yes - so we better check we have a buffer
    if (_buffer == null)
        _buffer = _buffers.getBuffer();

    // Copy _content to buffer;
    int len=_buffer.put(_content);
    _content.skip(len);
    if (_content.length() == 0)
        _content = null;
}

我的理解，_bypass变量标志不使用缓存，直接将数据刷到客户端，如果这是jetty8的新增特性，那么也不应该是到外层再调用blockforoutput方法，而是直接flushbuffer即可。很明显这是一个bug，bypass的判断条件有误，_buffer为空，这是不使用缓存的条件，但是_buffer.length() == 0并不是该特性的条件，每一次初始化的时候都会默认操作_buffer使得_buffer.length() == 0。这样就导致了每一包数据都走进了blockforoutput流程。应该是一个明显的笔误，问题的修改方法即是去掉该不当的判断条件，只保留_buffer==null的判断。

 

同前面的jetty若干性能问题的分析一样，这个问题的分析也耗费了大量的时间和精力，最终是借助于比对jetty7和jetty8的代码和不停的加日志打点调试得出的。每一个问题的解决都是一段辛酸的故事。