Java&Go 高性能队列之 channel 性能测试

之前写了两篇 Java 的高性能队列性能测试实践文章，发现了一些比较通用的规律，总体上Disruptor性能是要领先LinkedBlockingQueue的。先回顾一下Java&Go 高性能队列之 LinkedBlockingQueue 性能测试，Java&Go 高性能队列之 Disruptor 性能测试。

那么理论上性能更高的 Go 语言中的channel（下文中的也称为队列）性能如何呢，下面我将对它进行同样的性能测试。

测试场景设计的思路与前两篇文章相同，通过三个场景对变量的修改进行对比压测，包括不限于数量、大小、goroutine 的数量。

结论

总体来说channel性能还是在性能足够高，完全满足现在压测需求。总结起来几点比较通用的参考：

• Go 语言 channel 性能足够好，首先与生产者生产能力，工作中需要提升生产能力
• 消息体越小越好
• channel 的 size 长度并不重要
• 创建请求对象上fasthttp.Request居然还不如net/http.Request，可能跟没有 release 掉有关。

简介

Go 语言中的通道（channel）是一种特殊的类型。通道像一个传送带或者队列，总是遵循先入先出（First In First Out）的规则，保证收发数据的顺序。每一个通道都是一个具体类型的导管，也就是声明 channel 的时候需要为其指定元素类型。如果说 goroutine 是 Go 程序并发的执行体，channel 就是它们之间的连接。channel 是可以让一个 goroutine 发送特定值到另一个 goroutine 的通信机制。

在我查资料的过程中，发现 Go 语言在锁解决（多协程/多 goroutine 安全）的层面有很多很优秀的功能，显示在不同场景下会比channel性能更高。但是我在阅读 goreplay 源码的过程中，看到的更多还是channel的实践。等我逐步提高自己 Go 语言多协程编程能力之后再来测试其他实现。

测试结果

这里性能只记录每毫秒处理消息（对象）个数作为评价性能的唯一标准。在我测试Disruptor框架的过程中，发现这个单一指标有点有失偏颇，后续如果还有下一轮的测试的话，我再优化这个地方。

数据说明

这里我用了三种net/http中的Request，创建方法均使用原生 API，为了区分大小的区别，我会响应增加一些 header 和 URL 长度。

小对象：

get, _ := http.NewRequest("GET", base.Empty, nil)

中对象：

get,_ := http.NewRequest("GET",base.Empty, nil)
get.Header.Add("token", token)
get.Header.Add("Connection", base.Connection_Alive)
get.Header.Add("User-Agent", base.UserAgent)

大对象：

get,_ := http.NewRequest("GET",base.Empty, nil)
get.Header.Add("token", token)
get.Header.Add("token1", token)
get.Header.Add("token2", token)
get.Header.Add("token3", token)
get.Header.Add("token4", token)
get.Header.Add("token5", token)
get.Header.Add("Connection", base.Connection_Alive)
get.Header.Add("User-Agent", base.UserAgent)

生产者

针对net/http中的Request消息体结论如下：

1. 长度在 50 万 ~ 1000 万没有明显差异
2. 生产者越多越好（20 以内，再多增益效果不明显）
3. 消息体尽可能小

消费者

针对net/http中的Request消息体结论如下：

1. 长度在 50 万 ~ 500 万没有明显差异
2. 消费者 10 ~ 20 以内到达峰值
3. 消息体尽可能小

消费者并发越多越好，这个在实际工作中消费者消费消息会有耗时，消费者 goroutine 会很多，要根据实际情况设置消费者数量，或者在压测过程中灵活增减消费者数量，这点跟Disruptor不同。

生产者 & 消费者

这里的线程数指的是生产者或者消费者的数量，总体线程数是此数值的 2 倍。

针对net/http中的Request消息体结论如下：

1. 消息队列积累消息对性能影响不大
2. 消费次数越多，性能反而有点下降，应该是生产者速率不足导致
3. 消息体尽可能小，不过性能下降不多

测试用例

总体代码逻辑与 Java 和 Groovy 用例一样，有几处差别如下：

这里我用了sync.WaitGroup代替了java.util.concurrent.CountDownLatch，暂时没有找到合适的功能替换java.util.concurrent.CyclicBarrier，经过测试并不影响测试结果，所以略过此项。

Go语言的channel有个先天的优势，就是必需得设置size，相当于提前分配内存了。这点是我之前没想到的，当我回去复测LinkedBlockingQueue的时候发现并没有明显的性能差异，对于测试结果影响可忽略。

我还用了atomic.AddInt32解决计数安全的问题，这里不多分享了，有兴趣可以搜一下官方文档学习使用。

生产者场景

func TestQueue(t *testing.T) {
    var index int32 = 0
    rs := make(chan *http.Request, total+10000)
    var group sync.WaitGroup
    group.Add(threadNum)
    milli := futil.Milli()
    funtester := func() {
        go func() {
            for {
                l := atomic.AddInt32(&index, 1)
                if l%piece == 0 {
                    m := futil.Milli()
                    log.Println(m - milli)
                    milli = m
                }
                if l > total {
                    break
                }
                get := getRequest()
                rs <- get
            }
            group.Done()
        }()
    }
    start := futil.Milli()
    for i := 0; i < threadNum; i++ {
        funtester()
    }
    group.Wait()
    end := futil.Milli()

    log.Println(atomic.LoadInt32(&index))
    log.Printf("平均每毫秒速率%d", total/(end-start))
}

消费者场景

func TestConsumer(t *testing.T) {
    rs := make(chan *http.Request, total+10000)
    var group sync.WaitGroup
    group.Add(10)
    funtester := func() {
        go func() {
            for {
                if len(rs) > total {
                    break
                }
                get := getRequest()

                rs <- get
            }
            group.Done()
        }()
    }
    for i := 0; i < 10; i++ {
        funtester()
    }
    group.Wait()
    log.Printf("造数据完成! 总数%d", len(rs))
    totalActual := int64(len(rs))
    var conwait sync.WaitGroup
    conwait.Add(threadNum)
    consumer := func() {
        go func() {
        FUN:
            for {
                select {
                case <-rs:
                case <-time.After(10 * time.Millisecond):
                    break FUN
                }
            }
            conwait.Done()
        }()
    }
    start := futil.Milli()
    for i := 0; i < threadNum; i++ {
        consumer()
    }
    conwait.Wait()
    end := futil.Milli()
    log.Printf("平均每毫秒速率%d", totalActual/(end-start))

}

生产者 & 消费者 场景

这里我引入了另外一个变量：初始队列长度 length，用例运行之前将队列按照这个长度进行单线程填充。

func TestConsumer(t *testing.T) {
    rs := make(chan *http.Request, total+10000)
    var group sync.WaitGroup
    group.Add(10)
    funtester := func() {
        go func() {
            for {
                if len(rs) > total {
                    break
                }
                get := getRequest()

                rs <- get
            }
            group.Done()
        }()
    }
    for i := 0; i < 10; i++ {
        funtester()
    }
    group.Wait()
    log.Printf("造数据完成! 总数%d", len(rs))
    totalActual := int64(len(rs))
    var conwait sync.WaitGroup
    conwait.Add(threadNum)
    consumer := func() {
        go func() {
        FUN:
            for {
                select {
                case <-rs:
                case <-time.After(10 * time.Millisecond):
                    break FUN
                }
            }
            conwait.Done()
        }()
    }
    start := futil.Milli()
    for i := 0; i < threadNum; i++ {
        consumer()
    }
    conwait.Wait()
    end := futil.Milli()
    log.Printf("平均每毫秒速率%d", totalActual/(end-start))

}

生产对象

func getRequest() *http.Request {
    //get, _ := http.NewRequest("GET", base.Empty, nil)

    //get,_ := http.NewRequest("GET",url, nil)
    //get.Header.Add("token", token)
    //get.Header.Add("Connection", base.Connection_Alive)
    //get.Header.Add("User-Agent", base.UserAgent)

    get,_ := http.NewRequest("GET",url, nil)
    get.Header.Add("token", token)
    get.Header.Add("token1", token)
    get.Header.Add("token2", token)
    get.Header.Add("token3", token)
    get.Header.Add("token4", token)
    get.Header.Add("token5", token)
    get.Header.Add("Connection", base.Connection_Alive)
    get.Header.Add("User-Agent", base.UserAgent)

    return get
}

基准测试

下面是我使用 FunTester（Go 语言版本）性能测试框架对三种消息对象的生产代码进行的测试结果。没想到net/http的性能还不如 Java 的，有点奇怪。

下面是fasthttp.Request的基准测试结果：

fasthttp.Request居然还不如net/http.Request，有点奇怪。

测试用例如下：

// TestBase
// @Description: 基准测试
// @param t
func TestBase(t *testing.T) {
    execute.ExecuteRoutineTimes(func() {
        getRequest()
    },total,threadNum)
}

Have Fun ~ Tester ！

• FunTester2021 年总结
• FunTester 原创大赏
• Groovy 语言学习笔记大赏【FunTester】
• Golang 语言 HTTP 客户端实践
• 反射访问和修改 private 变量
• 如何突破职业瓶颈
• 如何选择 API 测试工具
• 如何从测试自动化中实现价值
• Groovy 中的 list
• 重放浏览器请求多链路性能测试实践
• 性能测试如何减少本机误差
• 莫要寻找可能不存在的答案
• 分段随机实践—模拟线上流量
• 千万级日志回放引擎设计稿