线上又报502了?不如试试go,实例证明php被go虐成渣

2023-02-17 23:05:12 373 林溪

背景交代

  • 前一段时间,每当有新项目上线,或者爬虫来爬的时候,服务器基本上就爆满了。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);
    }
在这里插入图片描述
  • 一个是用gin+gorm写的一个获取列表的方法,两者返回一致
在这里插入图片描述

性能对比

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