php和go语言的速度性能对比

背景交代

• 前一段时间，每当有新项目上线，或者爬虫来爬的时候，服务器基本上就爆满了。MySQL直接就宕机了。
• 为了解决这种情况，我们使用es来支持数据的检索，提供服务。MySQL的问题解决了，但是网站还是支持不了高并发。访问量一大就返回502。
• 我们先来看响应50x能带给我们什么信息50x的报错信息
• 500，是指上游服务器错误，如果是PHP，也可以说是fastcgi的错误 ，比如在解释器（zend引擎，可以算是一个微型的虚拟机）解释代码的时候发现版本不匹配，或者php语法错误，就会报500
• 502是也是指上游服务器错误，但不是代码层面的问题,这个错误往往是php响应超时造成的，或者php内存太小，我们可以通过php.ini来合理配置相关的参数
• 504则是Nginx抛给用户的错误，比如php我设置了超时5s,但是Nginx设置了超时1s,如果程序响应超过了Nginx规定的时间，或者Nginx一下子接收的请求太多了，根本没时间处理，超时了，则Nginx返回504给用户，这个超时是可用通过设置nginx.conf来调优的

定位错误

• 通过分析日志我们发现，大部分的报错是502，那么就定位是php的问题
• 另一方面，我们的接口也很不稳定，有时候快，有时候慢，刚开始以为是es的问题，但是我们通过分段打印日志，发现es没有问题，而是php有时候响应有7-9s。
• 但是提供同样的服务和数据，有一个接口却从来不会超时，响应都在毫秒级。这个接口就是go写的。go和php性能测试代码展示
• go和php对于高并发的差别到底有多大呢，我想通过实际的测试，来和大家一起看一下
• 我写了两个接口， 一个是laravel写的获取列表的方法

    public function list()
    {
        $sql="select * from cms_blog limit 20";
        $list=DB::select($sql);
        return $this->success($list);
    }

性能对比

• 为了模拟高并发下的性能，我们使用jmeter
• 这里面的设置解释一下：线程数20，也代表并发数。线程在10s内全部开启。每个线程循环100次，也就是说一共发送20*100个请求
  
• 添加聚合报告和结果树
• 添加http请求
  
• 执行完毕之后查看结果，关注一下四个指标，平均值，90%百分位，异常和吞吐量，我们看到在20个并发下没有任何异常，感觉不错，
  测试php并发量
• 我们必须得找到一个统一的标准来测试，所以我们要找出异常指标为0的情况下最大请求数
• 我们把20个并发改成200个再看一下，已经有异常了，我们关闭
  
• 100-200之间再取150试一下，还是有异常，php处理不过来，抛错误502了
  
• 使用二分法不断测试最大承受并发量，并发120，10s内发送请求12000个，我们得到指标如下
• 并发:120
• 吞吐量：90.8(每秒处理请求数)
• 90请求时间：1834（单位是毫秒，也就是90%的请求都是在1.8s内完成的）
• 平均请求时间：1204
  用相同方法测试go并发量
• go相关代码

func (t *BlogController) GetList(c *gin.Context) {
    blog:=model.BlogModel{}
    List := blog.GetList()
    c.JSON(200, gin.H{
        "code":10000,
        "msg": "ok",
        "data": List,
    })
    return
}

func (m *BlogModel) GetList() ([]Blog) {
    list := make([]Blog, 0)
    err := Db.Limit(20).Find(&list).Error
    if err != nil {
        return nil
    }
    return list
}

• 我们先来看看在相同并发下，go的表现怎么样
  
• 在并发120的情况下，得出以下数据
• 并发:120
• 吞吐量：1122(每秒处理请求数) ，是PHP的10倍左右
• 90请求时间：42（单位是毫秒），只有PHP的1/400
• 平均请求时间：20 只有PHP的1/600
• 为了性能的考虑，我们加入超时机制，响应时间限制为2s以内,相关代码如下

func (t *BlogController) GetList(c *gin.Context) {
    var res []model.Blog
    // 在规定时间内返回成功进入success
    var success = make(chan []model.Blog)
    //设置超时时间2s
    ctx, cancel := context.WithTimeout(c, 2*time.Second)

    defer cancel()

    go func() {
        wg := sync.WaitGroup{}
        wg.Add(1)
        defer wg.Done()
        blog := model.BlogModel{}
        res, err := blog.GetList()
        if err != nil {
            fmt.Println("i got an error")
            fmt.Println(err)
            success <- nil
            return
        }
        success <- res
        wg.Wait()
    }()

    for {
        select {
        case res = <-success:
            c.JSON(200, gin.H{
                "code": 200,
                "msg":  "ok",
                "data": res,
            })
            return
        case <-ctx.Done():
            c.JSON(http.StatusBadGateway, gin.H{"code": 999})
            return
        }
    }

}

• 注意，处理err很重要，否则可能会导致有部分请求无响应func (m *BlogModel) GetList() ([]Blog, error) { list := make([]Blog, 0) err := Db.Limit(20).Find(&list).Error if err != nil { return nil, err } return list, nil }
• 我们再来测试一下，并发600有异常，大概并发是550左右
• 并发:550
• 吞吐量：1058.3(每秒处理请求数) ，这里的吞吐量增加，和开启goroutine有关系
• 90请求时间：770（单位是毫秒，也就是90%的请求都是在1.8s内完成的）
• 平均请求时间：407
  
• 如果限制吞吐量（一秒内处理的请求数，也称为rps Requests Per Second 的缩写,相对于qps Queries Per Second 的缩写，更能反映系统的实际处理能力。）的话，并发量（同一个时间点处理的线程数）还可以继续增加。比如下面我设置rps为500，我们看一下
  
• 这里我开启了800并发，总共发起请求是80000个，限制rps 500左右，发现并发能力大大增强，而且每个请求的相应时间更短，但是，要处理掉全部的请求，时间变长了。感觉cpu有点像消化系统，吃的太多，反而响应变慢了。如果细粒度喂养，就会响应更快