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

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);
    }
php和go语言的速度性能对比

性能对比

  • 为了模拟高并发下的性能,我们使用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有点像消化系统,吃的太多,反而响应变慢了。如果细粒度喂养,就会响应更快

作者:JackLee,如若转载,请注明出处:https://www.wlwlm.com/article/5858.html

JackLee的头像JackLee超级管理员
上一篇 2024年4月6日 下午8:18
下一篇 2024年4月11日

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注